{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-headers-7.0.0-38-generic", "linux-image-7.0.0-38-generic", "linux-modules-7.0.0-38-generic", "linux-riscv-7.0-headers-7.0.0-38", "linux-riscv-7.0-tools-7.0.0-38", "linux-tools-7.0.0-38-generic" ], "removed": [ "linux-headers-7.0.0-34-generic", "linux-image-7.0.0-34-generic", "linux-modules-7.0.0-34-generic", "linux-riscv-7.0-headers-7.0.0-34", "linux-riscv-7.0-tools-7.0.0-34", "linux-tools-7.0.0-34-generic" ], "diff": [ "apparmor", "bind9-dnsutils", "bind9-host", "bind9-libs:riscv64", "curl", "dracut-install", "libapparmor1:riscv64", "libarchive13t64:riscv64", "libcurl3t64-gnutls:riscv64", "libcurl4t64:riscv64", "libevent-core-2.1-7t64:riscv64", "libfreetype6:riscv64", "libheif-plugin-aomdec:riscv64", "libheif-plugin-aomenc:riscv64", "libheif1:riscv64", "libnss-systemd:riscv64", "libopeniscsiusr", "libpam-systemd:riscv64", "libpng16-16t64:riscv64", "libsgutils2-1.46-2:riscv64", "libssl3t64:riscv64", "libsystemd-shared:riscv64", "libsystemd0:riscv64", "libudev1:riscv64", "libx11-6:riscv64", "libx11-data", "libxml2:riscv64", "libxpm4:riscv64", "linux-headers-generic", "linux-headers-virtual", "linux-image-virtual", "linux-libc-dev:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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:riscv64", "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-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "to_version": { "source_package_name": "linux-meta-riscv-7.0", "source_package_version": "7.0.0-38.38.1~24.04.1", "version": "7.0.0-38.38.1~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Main version: 7.0.0-38.38.1~24.04.1", "" ], "package": "linux-meta-riscv-7.0", "version": "7.0.0-38.38.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Sarah Emery ", "date": "Sun, 27 Sep 2026 01:47:52 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-headers-virtual", "from_version": { "source_package_name": "linux-meta-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "to_version": { "source_package_name": "linux-meta-riscv-7.0", "source_package_version": "7.0.0-38.38.1~24.04.1", "version": "7.0.0-38.38.1~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Main version: 7.0.0-38.38.1~24.04.1", "" ], "package": "linux-meta-riscv-7.0", "version": "7.0.0-38.38.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Sarah Emery ", "date": "Sun, 27 Sep 2026 01:47:52 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-virtual", "from_version": { "source_package_name": "linux-meta-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "to_version": { "source_package_name": "linux-meta-riscv-7.0", "source_package_version": "7.0.0-38.38.1~24.04.1", "version": "7.0.0-38.38.1~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Main version: 7.0.0-38.38.1~24.04.1", "" ], "package": "linux-meta-riscv-7.0", "version": "7.0.0-38.38.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Sarah Emery ", "date": "Sun, 27 Sep 2026 01:47:52 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-libc-dev:riscv64", "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-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "to_version": { "source_package_name": "linux-meta-riscv-7.0", "source_package_version": "7.0.0-38.38.1~24.04.1", "version": "7.0.0-38.38.1~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Main version: 7.0.0-38.38.1~24.04.1", "" ], "package": "linux-meta-riscv-7.0", "version": "7.0.0-38.38.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Sarah Emery ", "date": "Sun, 27 Sep 2026 01:47:52 +0200" } ], "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-7.0.0-38-generic", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": null }, "to_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-38.38.1~24.04.1", "version": "7.0.0-38.38.1~24.04.1" }, "cves": [ { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-68105", "url": "https://ubuntu.com/security/CVE-2026-68105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix kernel panic during driver load failure Avoid kernel panic if MES init fails during driver load. The KIQ ring is falsely marked as ready as ASICs that use MES, KIQ is owned by MES. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] Call Trace: gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280 __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53 (cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68109", "url": "https://ubuntu.com/security/CVE-2026-68109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68114", "url": "https://ubuntu.com/security/CVE-2026-68114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit e4d99e04b2e9b13b97d3b17804c735f62689db23)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68431", "url": "https://ubuntu.com/security/CVE-2026-68431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate minimum PDU size for transform requests The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68138", "url": "https://ubuntu.com/security/CVE-2026-68138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: serialize qdisc_rtab_list against concurrent get/put qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68082", "url": "https://ubuntu.com/security/CVE-2026-68082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix two unsafe bare decodes in decode_lockers() decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-08 10:16:00 UTC" }, { "cve": "CVE-2026-68159", "url": "https://ubuntu.com/security/CVE-2026-68159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68163", "url": "https://ubuntu.com/security/CVE-2026-68163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_vma_mapped: fix device-private PMD handling Commit 65edfda6f3f2 (\"mm/rmap: extend rmap and migration support device-private entries\") introduced the concept of device-private PMD entries, but did not correctly update the rmap walk code to account for them. As a result, when page_vma_mapped_walk() encounters device-private PMD entries, it takes no action other than to acquire the PMD lock and exit. However this is highly problematic for two reasons - firstly, device private entries possess a PFN so check_pmd() needs to be called to ensure an overlapping PFN range. Secondly, and more importantly, if PVMW_MIGRATION is set the caller assumes the returned entry is a migration entry, resulting in memory corruption when the caller tries to interpret the device private entry as such. In addition, commit 146287290023 (\"mm/huge_memory: implement device-private THP splitting\") allowed device private PMDs to be split like THP mappings, but again did not update this code path. As a result, we might race a PMD split prior to acquiring the PMD lock. This patch addresses all of these issues by invoking check_pmd(), ensuring PMVW_MIGRATION is not set and checks whether a split raced us we do for PMD THP and migration entries. Instead of checking for a subset of the cases after taking the pmd_lock(), put device-private along with pmd_trans_huge() and pmd_is_migration_entry(). Also remove thp_migration_supported() as it is already guarded by pmd_is_migration_entry(). [akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68166", "url": "https://ubuntu.com/security/CVE-2026-68166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: prevent registration of special VMAs Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68170", "url": "https://ubuntu.com/security/CVE-2026-68170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix stale skb->sk reference on subflow close The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68177", "url": "https://ubuntu.com/security/CVE-2026-68177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Delay module ref count for \"enable_event\" trigger Triggers are now delayed from freeing, but can still be triggered until after the RCU grace period has ended. The freeing of the enable_event data is put into the private_data_free() callback, but the put of the module refcount is done immediately. It is possible that if a module is removed that has an event that would enable (or disable) it is still active, it can read the data of the module after it is removed causing a use-after-free bug. Move the trace_event_put_ref() that releases the module into the delayed callback so that the module can not be removed until any reference to its events are finished.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68191", "url": "https://ubuntu.com/security/CVE-2026-68191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix NULL pointer dereference in rhash table destroy When unbinding the ath12k driver, kernel NULL pointer dereferences occur in irq_work_sync() called from rhashtable_destroy(). Two hash tables are affected: 1. ath12k_link_sta hash table in ath12k_base 2. ath12k_dp_link_peer hash table in ath12k_dp The issue happens because the destroy functions are called unconditionally in cleanup paths, but the hash tables are only initialized late in their respective init functions. If the device was never fully started or if the init functions failed before initializing the hash tables, the pointers will be NULL. The issues are always reproducible from a VM because the MSI addressing initialization is failing. Call trace for ath12k_link_sta_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_link_sta_rhash_tbl_destroy+0x19/0x40 [ath12k] ath12k_core_stop+0xe/0x80 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Call trace for ath12k_dp_link_peer_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_dp_link_peer_rhash_tbl_destroy+0x29/0x50 [ath12k] ath12k_dp_cmn_device_deinit+0x21/0x140 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Fix this by adding NULL checks before calling rhashtable_destroy() in both destroy functions. The NULL check approach was chosen because the rhashtable pointer serves as the initialization state indicator. The init can fail at various points, leaving some components uninitialized. Checking the pointer directly is simpler than adding separate state flags that would need synchronization.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64586", "url": "https://ubuntu.com/security/CVE-2026-64586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: drain bus_reset work on device removal brcmf_fw_crashed() and the debugfs \"reset\" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs \"reset\" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. 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-68208", "url": "https://ubuntu.com/security/CVE-2026-68208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: Fix the error code of devm_kzalloc() in vip_probe_slice() In vip_probe_slice(), the error check for devm_kzalloc() incorrectly uses PTR_ERR_OR_ZERO() which returns 0 for NULL pointer. Return -ENOMEM for devm_kzalloc() failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68224", "url": "https://ubuntu.com/security/CVE-2026-68224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mali-c55: Fix possible ERR_PTR in enable_streams The media_pad_remote_pad_unique() function returns either a valid pointer or an ERR_PTR() on failure (-ENOTUNIQ if multiple links are enabled, -ENOLINK if no connected pad is found). The return value was assigned directly to isp->remote_src and dereferenced in the next line without checking for errors, which could lead to an ERR_PTR dereference. Add proper error checking with IS_ERR() before dereferencing the pointer. Also set isp->remote_src to NULL on error to maintain consistency with other error paths in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68237", "url": "https://ubuntu.com/security/CVE-2026-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: fix indefinite fence wait during GPU reset pre_reset only force-completes fences of MAPPED queues. A queue in any other state (e.g. mid-eviction) keeps its last_fence pending; after a GPU reset that fence never signals, so the eviction/suspend worker and process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and wedge the machine: INFO: task kworker/6:28 blocked for more than 120 seconds. Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu] Call Trace: dma_fence_wait_timeout+0x7e/0x130 amdgpu_userq_evict+0x67/0x140 [amdgpu] amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu] process_scheduled_works+0xa6/0x420 Force-complete every queue's fence regardless of state. The unmap and mark-hung step stays gated on MAPPED, since unmapping a queue that is not mapped is invalid. (cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68240", "url": "https://ubuntu.com/security/CVE-2026-68240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: publish dpagemap early to avoid device mapping leak on error drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68242", "url": "https://ubuntu.com/security/CVE-2026-68242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix NULL deref on sched_engine alloc failure Avoid using intel_context_put() before intel_context_init() in execlists_create_virtual() as the kref_put() inside would lead to NULL deref on the IOCTL path when sched_engine allocation fails. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68254", "url": "https://ubuntu.com/security/CVE-2026-68254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: require valid min/max vfreq for VRR Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68436", "url": "https://ubuntu.com/security/CVE-2026-68436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use kvzalloc to allocate struct dc struct dc has grown large over time (most of it the two inlined dc_scratch_space copies) and now sits close to the page allocator's 4 MiB contiguous allocation limit. Its actual size is not fixed by the source alone, it also depends on the compiler and the .config, so it can easily cross 4 MiB, e.g. with a newer GCC or a config change. dc_create() allocates it with kzalloc(). Once struct dc exceeds 4 MiB the request is rounded up to order 11 (8 MiB), which is above MAX_PAGE_ORDER, so the page allocator warns and returns NULL. dc_create() then fails, DM init fails and amdgpu probe aborts with -EINVAL: WARNING: mm/page_alloc.c:5197 at __alloc_frozen_pages_noprof+0x2f9/0x380 dc_create+0x38/0x660 [amdgpu] amdgpu_dm_init+0x2d9/0x510 [amdgpu] dm_hw_init+0x1b/0x90 [amdgpu] amdgpu_device_init.cold+0x150d/0x1e13 [amdgpu] amdgpu_driver_load_kms+0x19/0x80 [amdgpu] amdgpu_pci_probe+0x1e2/0x4c0 [amdgpu] dc_create() then returns NULL and DM init fails, which aborts the whole GPU init and makes amdgpu probe fail with -EINVAL (\"hw_init of IP block failed -22\"), leaving the display unusable. The subsequent amdgpu_irq_put() warnings during teardown are just fallout of unwinding a half-initialized device. struct dc is a software-only bookkeeping structure that is never handed to hardware DMA and is only ever kept as an opaque pointer, so it does not require physically contiguous memory. Allocate it with kvzalloc() (and free it with kvfree()) so that the allocator can fall back to vmalloc() when a contiguous allocation of that size is not available, which also avoids the MAX_PAGE_ORDER warning entirely. v2: - Rebase to amd-staging-drm-next. (cherry picked from commit 991e0516a8072f2292681c6ae98a924ab0e32575)", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68447", "url": "https://ubuntu.com/security/CVE-2026-68447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size from hardware without bounding it to the allocated BO region. If the HW field is larger than the queue's control stack allocation, memcpy reads past the BO into adjacent GTT memory and can leak kernel data to userspace. Store the page-aligned control stack BO size in mqd_manager and clamp checkpoint copies and reported checkpoint sizes to min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound for multi-XCC v9.4.3 checkpoint layout. (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3)", "cve_priority": "high", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68264", "url": "https://ubuntu.com/security/CVE-2026-68264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: Reset current_op in xe_pt_update_ops_init() xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it. After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind. Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry. Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(). v2 (Matt): - Add details in commit message. - Add Fixes tag and Cc to stable@vger.kernel.org (cherry picked from commit 046045543e530605c441063535e7dca0075369a6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68265", "url": "https://ubuntu.com/security/CVE-2026-68265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO's tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference (cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68267", "url": "https://ubuntu.com/security/CVE-2026-68267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists Unconditionally whitelisting OA registers is a security violation. Set RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers don't get whitelisted by default after probe, gt reset, resume and engine reset. (cherry picked from commit 90511bdcfda97211c01f1d945d4ea616578d8fca)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68273", "url": "https://ubuntu.com/security/CVE-2026-68273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68274", "url": "https://ubuntu.com/security/CVE-2026-68274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix buffer overflow in steered register list allocation The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt->fuse_topo.g_dss_mask, ...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68283", "url": "https://ubuntu.com/security/CVE-2026-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free freeing trigger private data Commit 61d445af0a7c (\"tracing: Add bulk garbage collection of freeing event_trigger_data\") moved the kfree() of event_trigger_data to a kthread that runs tracepoint_synchronize_unregister() before freeing. That removed the synchronization the trigger .free callbacks used to get implicitly and inline from trigger_data_free(). event_hist_trigger_free(), event_hist_trigger_named_free() and event_enable_trigger_free() free their satellite data (hist_data, cmd_ops, enable_data) right after trigger_data_free() returns. With the synchronization now deferred to the kthread, a concurrent tracepoint handler can still reach that data through the list_del_rcu()'d trigger, causing a use-after-free. The histogram teardown must stay synchronous: remove_hist_vars() and unregister_field_var_hists() have to detach a synthetic event from the histogram before the trigger-removal write returns, otherwise a following command races in and the synthetic-event removal fails with -EBUSY, as the trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait with the correct barrier - tracepoint_synchronize_unregister(), matching the free kthread - before freeing. The enable trigger has no such synchronous requirement, and a blocking synchronize there would re-serialize the path that commit deliberately deferred. Give it an optional private_data_free() callback that the free kthread runs after its grace period, and free enable_data from there.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68286", "url": "https://ubuntu.com/security/CVE-2026-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68287", "url": "https://ubuntu.com/security/CVE-2026-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix size calculations for 64-bit attributes net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68288", "url": "https://ubuntu.com/security/CVE-2026-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68289", "url": "https://ubuntu.com/security/CVE-2026-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68291", "url": "https://ubuntu.com/security/CVE-2026-68291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix max_vport related crash on allocation error during init Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000 [ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000 [ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20 [ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000 [ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0 [ 320.417385] PKRU: 55555554 [ 320.417398] Call Trace: [ 320.417412] [ 320.417429] pci_device_remove+0x42/0xb0 [ 320.417459] device_release_driver_internal+0x1a9/0x210 [ 320.417492] driver_detach+0x4b/0x90 [ 320.417516] bus_remove_driver+0x70/0x100 [ 320.417539] pci_unregister_driver+0x2e/0xb0 [ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0 [ 320.417592] ? kmem_cache_free+0x31e/0x550 [ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190 [ 320.417644] ? do_syscall_64+0x38/0x6b0 [ 320.417665] do_syscall_64+0xc8/0x6b0 [ 320.417683] ? clear_bhb_loop+0x30/0x80 [ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 320.417727] RIP: 0033:0x7f963bb30beb", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68303", "url": "https://ubuntu.com/security/CVE-2026-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hvs/v3d: Fix null dereference in unbind The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68312", "url": "https://ubuntu.com/security/CVE-2026-68312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and cifs_close_deferred_file_under_dentry(), when a pending deferred close is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to add the file to the local processing list may fail under memory pressure. The loop breaks immediately, but the cancelled work is no longer pending (it would have called _cifsFileInfo_put()), and the cfile is never added to file_head for processing. The cifsFileInfo reference and the open server handle both leak. Fix by saving the cfile that failed allocation in a local variable, breaking as before, and calling _cifsFileInfo_put() on it after releasing the lock. Any files later in the iteration are unaffected since their deferred work is still pending and will fire normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68316", "url": "https://ubuntu.com/security/CVE-2026-68316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Fix element size accounting for cmd stream validation There are 2 issues with the element size handling in the command stream validation which result in too small of a size calculated when the element size is 16/32/64 bits. For NHWC format, the element size is simply missing from the calculation. The bitfield for the element size is different between IFM/IFM2 and OFM. IFM and IFM2 encode the precision in parameter bits 2:3, while OFM uses bits 1:2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68440", "url": "https://ubuntu.com/security/CVE-2026-68440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix heap overflow when reading module EEPROM txgbe_read_eeprom_hostif() always copies round_up(length, 4) bytes into the caller buffer, which ethtool allocates with exactly 'length' bytes. A non-4-aligned length therefore causes an out-of-bounds write. Copy only the remaining bytes on the final dword instead.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68323", "url": "https://ubuntu.com/security/CVE-2026-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: serialize udp bearer replicast list updates tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68441", "url": "https://ubuntu.com/security/CVE-2026-68441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected. This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d (\"bpf: add bpf_redirect() helper\"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available. commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs. Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a wrapper around tcf_classify() for use by qdisc classify functions and tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT, the wrapper converts it to TC_ACT_SHOT, dropping the packet rather than letting it continue silently. Dropping is preferred over letting the packet through because the user immediately sees packet loss. Silently passing the packet through would hide the problem and leave the user wondering why their redirect is not working. The clsact fast path, tc_run() continues to call tcf_classify() directly and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by sch_handle_egress/ingress() calling skb_do_redirect() as before.", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68337", "url": "https://ubuntu.com/security/CVE-2026-68337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject redirect helpers without a bpf_net_context The bpf_redirect*() helpers and skb_do_redirect() obtain the per-task bpf_redirect_info via bpf_net_ctx_get_ri(), which dereferences the current->bpf_net_context unconditionally. That context is established on the paths that run tc BPF such as sch_handle_{ingress,egress}(), *except* for the case where {cls,act}_bpf was attached to a proper qdisc. A program running from there reaches the NULL deref in two ways: * It calls bpf_redirect() directly, which dereferences the context at the top of the helper: tc qdisc add dev eth0 root handle 1: red limit 1MB min 10KB max 20KB \\ avpkt 1000 burst 100 qevent early_drop block 10 tc filter add block 10 pref 1 bpf obj redirect.o * It simply returns TC_ACT_REDIRECT without helper call: tcf_qevent_handle() then dispatches to skb_do_redirect(), which dereferences the context Rather than extending bpf_net_context management into the qdisc path, make the redirect helpers refuse to operate when no context exists, and have tcf_qevent_handle() drop a TC_ACT_REDIRECT verdict instead of calling skb_do_redirect(). Previous behaviour was a crash, so nothing regresses by not supporting it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68345", "url": "https://ubuntu.com/security/CVE-2026-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm_mpam: guard MBWU state before adding it to garbage __destroy_component_cfg() adds each RIS mbwu_state object to the MPAM garbage list when destroying component configuration. However, mbwu_state is allocated per RIS and only for RISes with MBWU monitors. A component can therefore have comp->cfg allocated while some RISes still have ris->mbwu_state set to NULL. Passing a NULL mbwu_state to add_to_garbage() dereferences the NULL pointer inside the macro. Skip RISes that do not have an mbwu_state object before adding them to the garbage list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68347", "url": "https://ubuntu.com/security/CVE-2026-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68375", "url": "https://ubuntu.com/security/CVE-2026-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle partially initialized auxiliary devices bnxt_aux_devices_init() calls auxiliary_device_init() before all fields used by bnxt_aux_dev_release() are initialized. After auxiliary_device_init() succeeds, later errors must unwind with auxiliary_device_uninit(), which invokes the release callback. The release callback assumes that aux_priv->id, aux_priv->edev, edev->net and edev->ulp_tbl are all populated. If allocation fails after auxiliary_device_init(), the release path can otherwise dereference or clear partially initialized state. Allocate and attach the bnxt_en_dev and ULP table before calling auxiliary_device_init(), so the release callback only sees a fully initialized auxiliary private object. If auxiliary_device_init() itself fails, free those allocations directly because device_initialize() has not run and the release callback will not be invoked. 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-68382", "url": "https://ubuntu.com/security/CVE-2026-68382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Hold device ref until queue teardown completes GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock. Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending. Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work. With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. Replace the fini wait with an assertion and remove the unused fini_wq. v2: - Rebase v3: - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt) - Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt) - Drop separate deferred drm_dev_put worker. - Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini(). v4: - Replace the guc_submit_sw_fini() wait with an assertion and remove the now-unused fini_wq. (sashiko) v5: - Move destroy work to a module-lifetime Xe workqueue instead of system_dfl_wq. (Matt) - Flush the module-lifetime destroy workqueue during PCI remove to preserve the old device-remove wait semantics. v6: - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid letting it outlive the xe_device/drm_device. (Sashiko) - Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work can be queued from the reclaim path. v7: - Drop the per-device xe->destroy_wq and use the module-level destroy WQ for SVM pagemap destroy as well. (Matt) - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*() helpers because the WQ is no longer exec-queue specific. (Matt) v8: - Rebase. v9: - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM destroy_wq because it can be queued from reclaim and embeds the dev_pagemap used by devres teardown. (Sashiko) - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM from it. - Update the module-WQ kdoc to document the GuC/SVM split. v10: - Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the workqueue allocation warning. v11: - Drop the SVM pagemap destroy comment as it was revision-specific. (Thomas) v12: - Rebase. (cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68383", "url": "https://ubuntu.com/security/CVE-2026-68383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Keep scheduler timeline name alive The scheduler keeps a pointer to the timeline name, but q->name is freed with the exec queue while scheduler fences can still reference it. Store the name in struct xe_guc_exec_queue so it shares the scheduler's RCU-deferred lifetime. (cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68390", "url": "https://ubuntu.com/security/CVE-2026-68390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups hci_conn_params_lookup requires hdev->lock be held, otherwise the list iteration or param access is not safe. Hold hdev->lock for params lookups in hci_sync.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-2026-68404", "url": "https://ubuntu.com/security/CVE-2026-68404", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: use wiphy work for socket owner autodisconnect nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68367", "url": "https://ubuntu.com/security/CVE-2026-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: synchronize delayed set_alt with teardown The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68095", "url": "https://ubuntu.com/security/CVE-2026-68095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse-uring: fix race between registration and connection abortion This fixes this race: - thread a: io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref yet - thread b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() is a no-op due to queue ref being 0 - thread a: grabs the queue_ref, queue_ref is now 1, rest of fuse_uring_do_register() logic executes - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs and calls \"wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);\" The abort/unmount thread will hang indefinitely in unkillable state as nothing will decrement queue_refs or wake stop_waitq, and the ring, queue, and ent are leaked. Fix this by checking fch->connected under fch->lock after the created ent has grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either release the queue ref and wake up stop_waitq (in case fuse_chan_wait_aborted() is already waiting) in fuse_uring_do_register() when we detect !fch->connected, or if the connection is aborted after the check, it is guaranteed that the async teardown worker will be running in the background cleaning up ents and decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-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-68173", "url": "https://ubuntu.com/security/CVE-2026-68173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: wait on ublk_dev_ready() instead of ub->completion ub->completion is only re-armed by a successful START_USER_RECOVERY. If the ublk server sends END_USER_RECOVERY without one - e.g. its START failed with -EBUSY and the error was ignored - the wait is satisfied by the stale completion of the previous recovery cycle, and the device is marked LIVE and the requeue list kicked while the FETCH stream is still running and ubq->canceling is still set. The kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it again via __ublk_abort_rq(), and after the last FETCH clears ->canceling nothing ever kicks the requeue list again: the request is stranded there while holding its tag. If it is the flush machinery's flush_rq, every subsequent fsync piles up in uninterruptible sleep and teardown hangs on tag draining. This matches a report of a lost PREFLUSH with ext4 on top of ublk after daemon crash recovery. ub->completion is an edge-triggered latch used as a proxy for the level condition \"every queue has fetched all I/O commands\", which can regress (F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop it and wait on the real condition instead: the new helper ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then re-checks it under ub->mutex, waiting again on regression, and returns with the mutex held and readiness guaranteed. Readiness becomes true in the same ub->mutex critical section that clears the last queue's ->canceling, so END_USER_RECOVERY marks the device LIVE and kicks the requeue list strictly after ->canceling clears. The wait stays interruptible, so a server whose daemon died can still be signalled out. For ublk_ctrl_start_dev() this replaces the fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting until the device is ready again.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68113", "url": "https://ubuntu.com/security/CVE-2026-68113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68118", "url": "https://ubuntu.com/security/CVE-2026-68118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: challenge ACK for non-exact RST in SYN-RECEIVED The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68120", "url": "https://ubuntu.com/security/CVE-2026-68120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtase: Workaround for TX hang caused by hardware packet parsing The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission.", "cve_priority": "medium", "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-68122", "url": "https://ubuntu.com/security/CVE-2026-68122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix peer refcount leak in TCP error paths When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&peer->tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object. The race window: CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error): ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2 schedule_work() <- queued schedule_work() <- NO-OP (work already pending) ovpn_tcp_peer_del_work runs: ovpn_peer_del() ovpn_peer_put() <- refcnt+1 <- peer never freed Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68128", "url": "https://ubuntu.com/security/CVE-2026-68128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: reject out-of-range ptype in ice_parser_profile_init set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from providing ptype >= 1024 through VIRTCHNL, resulting in a write past the end of the bitmap and a kernel page fault. Reproduced with a custom kernel module injecting a crafted VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1. crash_parser: ice_parser_profile_init @ ffffffffc0d61b60 crash_parser: setting ptype=0xffff (max valid=1023) crash_parser: calling ice_parser_profile_init -- expect OOB crash! BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace: ? __pfx_ice_parser_profile_init+0x10/0x10 [ice] crash_init+0x127/0xff0 [crash_parser] do_one_initcall+0x45/0x310 do_init_module+0x64/0x270 init_module_from_file+0xcc/0xf0 idempotent_init_module+0x17b/0x280 __x64_sys_finit_module+0x6e/0xe0 Bail out early with -EINVAL when ptype is out of range.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68132", "url": "https://ubuntu.com/security/CVE-2026-68132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: super: fix emergency thaw deadlock on frozen block devices do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68133", "url": "https://ubuntu.com/security/CVE-2026-68133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP Call Trace during PTP release If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will result in the following PTP release call trace during driver unload: kernel BUG at lib/list_debug.c:52! ice_ptp_release+0x332/0x3c0 [ice] ice_deinit_features.part.0+0x10e/0x120 [ice] ice_remove+0x100/0x220 [ice] This was observed when passing PF1 through to a VM. ice_ptp_init() fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT. Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and returning without error, preventing the invalid state transition to ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from ICE_PTP_RESETTING after a failed rebuild.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68134", "url": "https://ubuntu.com/security/CVE-2026-68134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: ptp_s390: Add missing facility check Only register the physical clock when facility 28 is installed and PTFF QAF returns that PTFF QPT is available.", "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-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-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-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-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-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-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-68150", "url": "https://ubuntu.com/security/CVE-2026-68150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/super: fix emergency thaw double-unlock of s_umount do_thaw_all() iterates over all superblocks via __iterate_supers() with SUPER_ITER_EXCL, which acquires s_umount exclusively before calling the callback and releases it afterwards. However, the callback do_thaw_all_callback() calls thaw_super_locked() which unconditionally releases s_umount on every code path. This results in a second unlock attempt in __iterate_supers() that corrupts the rwsem state, triggering a DEBUG_RWSEMS warning: [ 182.601148] sysrq: Emergency Thaw of all frozen filesystems [ 182.601865] ------------[ cut here ]------------ [ 182.602375] DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff99b1011e5870, owner = 0x0, curr 0xffff99b101b06c80, list not empty [ 182.603817] WARNING: kernel/locking/rwsem.c:1412 at up_write+0xa3/0x170, CPU#2: kworker/2:1/53 [ 182.604578] Modules linked in: [ 182.604864] CPU: 2 UID: 0 PID: 53 Comm: kworker/2:1 Not tainted 7.2.0-rc4-00001-gbd3bd93ea98a-dirty #4 PREEMPT(lazy) [ 182.605711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014 [ 182.606417] Workqueue: events do_thaw_all [ 182.606750] RIP: 0010:up_write+0xaf/0x170 [ 182.607076] Code: 19 3a 92 48 0f 44 c2 48 8b 55 08 48 8b 55 00 4c 8b 45 08 48 8b 55 00 48 8d 3d ad 91 e0 01 48 8b 4d 20 50 48 c7 c6 f0 8c 26 92 <67> 48 0f b9 3a e8 d7 93 4e 00 58 eb 81 48 83 7f 18 00 48 c7 c2 8d [ 182.608563] RSP: 0018:ffffb670001d7e08 EFLAGS: 00010246 [ 182.609007] RAX: ffffffff92349e8d RBX: 0000000000000000 RCX: ffff99b1011e5870 [ 182.609595] RDX: 0000000000000000 RSI: ffffffff92268cf0 RDI: ffffffff92914d10 [ 182.610283] RBP: ffff99b1011e5870 R08: 0000000000000000 R09: ffff99b101b06c80 [ 182.610847] R10: ffff99b10139a808 R11: fefefefefefefeff R12: 0000000000000000 [ 182.611414] R13: ffffffff90cf74d0 R14: 0000000000000000 R15: ffff99b1011e5800 [ 182.612009] FS: 0000000000000000(0000) GS:ffff99b1eaaee000(0000) knlGS:0000000000000000 [ 182.612670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 182.613146] CR2: 00000000005c631c CR3: 00000000013ee000 CR4: 00000000000006f0 [ 182.613722] Call Trace: [ 182.613946] [ 182.614130] __iterate_supers+0x128/0x150 [ 182.614463] do_thaw_all+0x1b/0x30 [ 182.614759] process_scheduled_works+0xbb/0x3f0 [ 182.615150] ? __pfx_worker_thread+0x10/0x10 [ 182.615499] worker_thread+0x129/0x270 [ 182.615816] ? __pfx_worker_thread+0x10/0x10 [ 182.616201] kthread+0xe2/0x120 [ 182.616469] ? __pfx_kthread+0x10/0x10 [ 182.616792] ret_from_fork+0x15b/0x240 [ 182.617115] ? __pfx_kthread+0x10/0x10 [ 182.617426] ret_from_fork_asm+0x1a/0x30 [ 182.617761] [ 182.617968] ---[ end trace 0000000000000000 ]--- [ 182.618412] Emergency Thaw complete Fix this by switching to SUPER_ITER_UNLOCKED and acquiring s_umount in the callback via super_lock_excl() before calling thaw_super_locked(). This matches the locking pattern expected by thaw_super_locked() and eliminates the double unlock. While at it, remove the dead 'return;' at the end of do_thaw_all_callback().", "cve_priority": "low", "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-68152", "url": "https://ubuntu.com/security/CVE-2026-68152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: fix use-after-free in AMT delayed works When an AMT device is removed, pending delayed works can still access the freed amt_dev structure, which may result in kernel crashes or memory corruption. amt_dev_stop() cancels req_wq and discovery_wq with cancel_delayed_work_sync(), but these works can be scheduled again from event_wq after the cancellation. This allows delayed works to access the freed amt_dev structure after the netdev has been released. The following is a simple race scenario: CPU0 CPU1 amt_dev_stop() cancel_delayed_work_sync() amt_event_work() mod_delayed_work(req_wq) free netdev req_wq accesses freed amt_dev Use disable_delayed_work_sync() in amt_dev_stop() to prevent req_wq and discovery_wq from being queued again and wait for running work items to complete. The delayed works are disabled after initialization in amt_newlink() and enabled only when the device is successfully opened. This keeps the delayed work lifecycle synchronized with the lifetime of the AMT device.", "cve_priority": "high", "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-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-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-68168", "url": "https://ubuntu.com/security/CVE-2026-68168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix afs_edit_dir_remove() to get, not find, block 0 Fix afs_edit_dir_remove() to use afs_dir_get_block() to get block 0 rather than afs_dir_find_block() as the latter caches the found block in the afs_dir_iter and may[*] switch out the page it's on if another afs_dir_find_block() is done. This parallels what afs_edit_dir_add() does. [*] There's more than one block per page.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68169", "url": "https://ubuntu.com/security/CVE-2026-68169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: userspace: fix use-after-free in get_local_id In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a \"not found\" sentinel.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68172", "url": "https://ubuntu.com/security/CVE-2026-68172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: make huge_ptep_get handled unaligned addresses huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma). The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned. On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map or into a hole, dereference a VA not mapped into the kernel pgtables and cause kernel panic. Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68174", "url": "https://ubuntu.com/security/CVE-2026-68174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix union collision of module and refcnt for dynamic events In 'struct trace_event_call', the 'module' pointer and the 'refcnt' atomic variable share the same memory space in a union. For dynamic events, the union member is 'refcnt', which acts as an active reference counter. When a dynamic event (such as kprobe, uprobe, fprobe, eprobe, or wprobe) has a non-zero reference count (e.g. due to active event triggers or perf attachments), its 'call->module' evaluates to a small non-zero integer instead of NULL. When filtering or setting events for a specific module (e.g., writing ':mod:' to 'set_event'), the code in '__ftrace_set_clr_event_nolock()' and 'update_event_fields()' reads 'call->module' directly without checking whether the event is dynamic. This causes the kernel to treat the small integer (refcnt) as a 'struct module' pointer, leading to a NULL/invalid pointer dereference (Oops) when dereferencing the module name. Fix this by ensuring that the 'TRACE_EVENT_FL_DYNAMIC' flag is checked before treating 'call->module' as a valid pointer in these code paths.", "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-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-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-68434", "url": "https://ubuntu.com/security/CVE-2026-68434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms Commit b1b4efea05a5 (\"serial: 8250_mid: Disable DMA for selected platforms\") replaced the dnv_board setup and exit callbacks with PTR_IF(false, ...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. Fix this by adding the missing NULL checks before calling the setup and exit callbacks.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17: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-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-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16: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-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-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-68198", "url": "https://ubuntu.com/security/CVE-2026-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix use-after-free in aggr_reset_state() The aggr_reset_state() function uses timer_delete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggr_module_destroy(). If the timer callback (aggr_timeout) is executing when aggr_reset_state() is called, the callback will continue to access aggr_conn fields like rx_tid[] and stat[] which may be freed immediately after by kfree(aggr_info->aggr_conn) in aggr_module_destroy(). Additionally, the timer callback can re-arm itself via mod_timer() while aggr_reset_state() is running, creating a more complex race condition. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "high", "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-68200", "url": "https://ubuntu.com/security/CVE-2026-68200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: don't re-enter an instance callback that is still running The userspace-driven timer (utimer) TRIGGER ioctl calls snd_timer_interrupt() directly with no serialization, so two threads triggering the same utimer can run snd_timer_interrupt() on one snd_timer concurrently. snd_timer_process_callbacks() drops timer->lock around each instance callback and marks the in-flight callback with the single SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that bit to drain an in-flight callback before freeing the instance. The bit cannot represent two concurrent callbacks: when a second interrupt re-queues an instance whose callback is still running, both run at once, the first to finish clears the bit, and the close-path drain then frees the instance (and its callback_data) while the other callback is still live - a use-after-free reachable by any user able to open /dev/snd/timer, both via a user timer instance and via a sequencer queue timer bound to the utimer. snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so a concurrent interrupt already observes it under the lock. Skip re-queuing an instance (and its slaves) to the ack/sack list while its callback is in flight; the accumulated pticks are delivered on the next tick, so no event is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68201", "url": "https://ubuntu.com/security/CVE-2026-68201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: drain a slave's callback before its master detaches it snd_timer_close_locked() drains the closing instance's own in-flight callback (IFLG_CALLBACK) before freeing it, but not its slaves'. When a master instance is closed, remove_slave_links() clears each slave's ->timer; the slave's own close then reads timer == NULL and takes the branch that skips the drain entirely (snd_timer_stop_slave() also no-ops on a NULL timer). So a slave whose callback is still running when the master is closed is freed underneath the live callback, leading to use-after-free. Drain the slaves too before remove_slave_links() severs them. snd_timer_stop() has already taken this instance off the active list, so no new slave callback can be queued. Take the slaves off the ack list so a pending one can't fire either, then wait for any that is already in flight.", "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-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-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-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-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-68211", "url": "https://ubuntu.com/security/CVE-2026-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32-dcmipp: 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. dcmipp_bytecap_start_streaming() returned -EINVAL when the source subdevice could not be resolved from the media graph, before pm_runtime_resume_and_get() and media_pipeline_start() had been called. The remaining error paths already converge on the err_buffer_done label, which calls dcmipp_bytecap_all_buffers_done(..., VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate err_pm_put / err_media_pipeline_stop 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": "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-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-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-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-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-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-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-68230", "url": "https://ubuntu.com/security/CVE-2026-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: amlogic-c3: Add validations for ae and awb config Avoid invalid memory access if the zones_num is bigger than zone_weight. This patch fixes the following smatch errors: drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max", "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-68232", "url": "https://ubuntu.com/security/CVE-2026-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path.", "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-68233", "url": "https://ubuntu.com/security/CVE-2026-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Shut down BO cache timer before teardown The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20: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-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-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-68238", "url": "https://ubuntu.com/security/CVE-2026-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Release VFCT ACPI table reference amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68239", "url": "https://ubuntu.com/security/CVE-2026-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Account for NULL and handle pages in ttm_pool_backup Pages in ttm_pool_backup can be NULL or backup handles (ttm_backup_page_ptr_is_handle()), neither of which can be passed to set_pages_array_wb() or freed. Add a dedicated WB pass before the dma/purge loop that walks allocations using the same i += num_pages stride, skipping NULL and handle entries, and calls set_pages_array_wb() once per contiguous run of real pages. Apply the same NULL/handle guard to the dma/purge loop. Fixes the following oops: Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI RIP: 0010:__cpa_process_fault+0xf8/0x770 RSP: 0018:ffffc90000a87718 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34 RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0 R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000 R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0 FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0 PKRU: 55555554 Call Trace: __change_page_attr_set_clr+0x989/0xe90 ? __purge_vmap_area_lazy+0x6c/0x3a0 ? _vm_unmap_aliases+0x250/0x2a0 set_pages_array_wb+0x7f/0x120 ttm_pool_backup+0x4c9/0x5b0 [ttm] ? dma_resv_wait_timeout+0x3b/0xf0 ttm_tt_backup+0x32/0x60 [ttm] ttm_bo_shrink+0x66/0x110 [ttm] xe_bo_shrink_purge+0x12b/0x1b0 [xe] xe_bo_shrink+0xbb/0x270 [xe] __xe_shrinker_walk+0xf7/0x160 [xe] xe_shrinker_walk+0x9d/0xc0 [xe] xe_shrinker_scan+0x11f/0x210 [xe] do_shrink_slab+0x13b/0x270 shrink_slab+0xf1/0x400 shrink_node+0x352/0x8a0 balance_pgdat+0x32c/0x700 kswapd+0x205/0x2f0 ? __pfx_autoremove_wake_function+0x10/0x10 ? __pfx_kswapd+0x10/0x10 kthread+0xd1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1b1/0x200 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68241", "url": "https://ubuntu.com/security/CVE-2026-68241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/mst: limit DP MST ESI service loop The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto. (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)", "cve_priority": "medium", "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-68245", "url": "https://ubuntu.com/security/CVE-2026-68245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only valid while the lock is still being held. Once xa_unlock_irqrestore is called and returned, the pointer is no longer under lock and is subject to modification. Since, the caller still dereferences vm->task_info in amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a use after unlock problem. Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid() through removing the amdgpu_vm_get_vm_from_pasid() function from amdgpu_vm.c and making the relevant code inline to hold the lock while it is still in use. (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)", "cve_priority": "high", "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-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-68252", "url": "https://ubuntu.com/security/CVE-2026-68252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68253", "url": "https://ubuntu.com/security/CVE-2026-68253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)", "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-68257", "url": "https://ubuntu.com/security/CVE-2026-68257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix 32-bit overflow in CWSR total size calculation total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68258", "url": "https://ubuntu.com/security/CVE-2026-68258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on CRIU restore queue type and mqd size We weren't checking whether the values provided in the private data in kfd CRIU restore were within bounds. For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it. For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations. (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)", "cve_priority": "low", "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-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-68266", "url": "https://ubuntu.com/security/CVE-2026-68266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68268", "url": "https://ubuntu.com/security/CVE-2026-68268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Return error on non-migratable faults requiring devmem Non-migratable faults that require devmem incorrectly jump to the 'out' label, which squashes the error code intended to be returned to the upper layers. Fix this by returning -EACCES instead. (cherry picked from commit c4508edb2c723de93717272488ea65b165637eac)", "cve_priority": "medium", "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-68270", "url": "https://ubuntu.com/security/CVE-2026-68270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Avoid possible truncation with calculating visible size Calculating the visible size of the system framebuffer can result in truncation of the result. The calculation uses 32-bit arithmetics, which can overflow if the values for height and stride are large. Fix the issue by multiplying with mul_u32_u32().", "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-68275", "url": "https://ubuntu.com/security/CVE-2026-68275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks up the bo_va for the buffer object in the caller's VM via amdgpu_vm_bo_find(), but uses the returned pointer without checking it. amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM, which is the normal case for a BO that has never been mapped. The result is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which expands to list_for_each_entry(mapping, &(bo_va)->valids, list) and dereferences bo_va, causing a NULL pointer dereference. This is reachable by any process able to issue the ioctl (render group) simply by requesting mapping info for an unmapped BO. Return -ENOENT when no bo_va is found, jumping to out_exec so the drm_exec context and GEM object reference are released. (cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68276", "url": "https://ubuntu.com/security/CVE-2026-68276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx: fix cleaner shader IB buffer overflow The cleaner shader sysfs path allocates a 16-dword (64 byte) IB but incorrectly fills (align_mask + 1) dwords. On GFX rings align_mask is 0xff, so the loop wrote 256 dwords into a 64-byte buffer, causing a kernel page fault. The IB only needs to be a minimal NOP shell to schedule the job; the cleaner shader itself is emitted on the ring via emit_cleaner_shader(). Fill 16 dwords to match the allocation. v2: Use ib_size_dw variable (Lijo) (cherry picked from commit bf21af331ebf72d0935fd70c73192414a422c03a)", "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-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-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-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-68282", "url": "https://ubuntu.com/security/CVE-2026-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: analogix_dp: Add missing error check for platform_get_resource() Add missing error check for platform_get_resource() return value to prevent NULL pointer dereference when memory resource is not available.", "cve_priority": "medium", "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-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-68292", "url": "https://ubuntu.com/security/CVE-2026-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues.", "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-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-68296", "url": "https://ubuntu.com/security/CVE-2026-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM Before commit 00d066a4d4ed (\"netdev_features: convert NETIF_F_LLTX to dev->lltx\"), NETIF_F_LLTX was set unconditionally in both __gre_tunnel_init() and ip6gre_tnl_init_features() alongside GRE_FEATURES: dev->features |= GRE_FEATURES | NETIF_F_LLTX; When that commit converted NETIF_F_LLTX to the dev->lltx flag, it placed 'dev->lltx = true' after the SEQ/CSUM early returns instead of before them. This causes GRE/GRETAP/ip6gre tunnels with SEQ or CSUM+encap to lose lockless TX, reintroducing _xmit_lock acquisition around their ndo_start_xmit. Since GRE xmit re-enters the stack via ip_tunnel_xmit(), holding _xmit_lock risks ABBA deadlock with the underlay device. CPU0 CPU1 ---- ---- lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); Fix by moving dev->lltx = true before the early returns in both functions, restoring the original unconditional behavior.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64575", "url": "https://ubuntu.com/security/CVE-2026-64575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: fix double sock release on batch realloc bpf_iter_tcp_batch() releases the current batch via bpf_iter_tcp_put_batch(), which drops the socket refs and rewrites each slot with the socket cookie, then grows the batch. cur_sk/end_sk are kept for bpf_iter_tcp_resume(), but on realloc failure the function returns ERR_PTR() before resume runs, leaving cur_sk < end_sk over slots that now hold cookies rather than sock pointers. bpf_iter_tcp_seq_stop() then calls bpf_iter_tcp_put_batch() again and dereferences a cookie as a struct sock. Empty the batch on the failure path so stop() does not release it again. The sockets were already freed by the first bpf_iter_tcp_put_batch(), so nothing leaks, and a later read() rescans the bucket from the start instead of skipping it. The sibling GFP_NOWAIT failure path still holds real socket references and is left for stop() to release. BUG: KASAN: null-ptr-deref in __sock_gen_cookie Read of size 8 at addr 0000000000000059 by task exploit ... __sock_gen_cookie (net/core/sock_diag.c:28) bpf_iter_tcp_put_batch (net/ipv4/tcp_ipv4.c:2918) bpf_iter_tcp_seq_stop (net/ipv4/tcp_ipv4.c:3270) bpf_seq_read (kernel/bpf/bpf_iter.c:205) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 entry_SYSCALL_64_after_hwframe Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68298", "url": "https://ubuntu.com/security/CVE-2026-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create() Commit 9e9787414882 (\"drm/xe/userptr: replace xe_hmm with gpusvm\") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a \"simple\" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). (cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4)", "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-68448", "url": "https://ubuntu.com/security/CVE-2026-68448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: check access to copy_file_range source with src mounter creds Commit 5dae222a5ff0c (\"vfs: allow copy_file_range to copy across devices\") allowed filesystems that implement the copy_file_range() f_op to decide if they want to access cross-sb copy from/to the same fs type. The same commit added checks to verify same sb copy for filesystems that implement ->copy_file_range() and do not support cross-sb copy at the time, namely, to ceph, fuse and nfs. The two remaining fs which implement ->copy_file_range(), cifs and overlayfs started to support cross-sb copy from this time. While overlayfs does support cross-sb copy when the two underlying files are on the same base fs, the copy operation on the two real files from two different overalyfs filesystems is performed with the mounter creds of the destination overlayfs and the read permission access hook for the source file was called with the wrong creds. This could cause either deny of access to copy which would otherwise be allowed (e.g. with splice) or allow read access to file which would otherwise be denied. Fix the latter case by explicitly verifying read access to source file with the source overlayfs mounter creds. The former case remains a quirk of cross-sb overlayfs copy, but userspace could fall back to regular copy so no harm done.", "cve_priority": "low", "cve_public_date": "2026-08-12 01:17: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-68307", "url": "https://ubuntu.com/security/CVE-2026-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix crash in reset link replay During reset recovery, mt7925_vif_connect_iter() replays firmware state for links tracked in mvif->valid_links. After MLO link changes or MCU timeout recovery, the driver bitmap can temporarily contain a link whose mac80211 bss_conf has already gone away. This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching the crash where x1, the second argument, is NULL: pc : mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] lr : mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] x2 : ffffff80a77f6018 x1 : 0000000000000000 x0 : ffffff8099402080 Call trace: mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common] Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA reset replay is unchanged because the helper still returns &vif->bss_conf for the legacy link.", "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-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-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-68311", "url": "https://ubuntu.com/security/CVE-2026-68311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: guard link STA in decap offload mt7925_sta_set_decap_offload() iterates over the vif valid_links mask when updating decap offload state for an MLO station. The station may not have a link STA for every valid link of the vif, so mt792x_sta_to_link() can return NULL for a link that belongs to the vif but not to the station. The function currently dereferences mlink before checking whether the link WCID is ready. If mlink is NULL, setting or clearing MT_WCID_FLAG_HDR_TRANS dereferences a NULL pointer. Skip links without a station link before touching mlink->wcid.", "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-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-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-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-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-68321", "url": "https://ubuntu.com/security/CVE-2026-68321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix FDIR filter leak on remove Perfect FDIR filters can be added while the interface is down and are kept on the software list for later restore. unregister_netdev() only calls ndo_stop when the device is up, so txgbe_fdir_filter_exit() in txgbe_close() is skipped in that case and the filters are leaked on driver remove. Free the filter list from txgbe_remove() as well.", "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-68330", "url": "https://ubuntu.com/security/CVE-2026-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix DMA direction for NPU mailbox buffer airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE, but some callers expect the NPU to write response data back into the same buffer: - airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into the buffer, then the caller reads it via memcpy() - airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back npu_stats_addr field in the response On non-cache-coherent architectures like EN7581 (Cortex-A53 without hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op — it does not invalidate the CPU cache. If the NPU-written cache line is still present in the CPU cache when the caller reads the buffer, the CPU observes stale data instead of the NPU response. This is a timing-sensitive bug: small mailbox buffers (~24 bytes) typically fit in a single cache line and may survive in the cache until the caller reads them, producing silent data corruption rather than a crash. The bug is more likely to trigger when the caller reads the response immediately after dma_unmap_single() without intervening cache-evicting operations. Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures dma_unmap_single() invalidates the CPU cache on non-coherent systems. The mailbox buffers are small so there is no performance concern.", "cve_priority": "low", "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-68332", "url": "https://ubuntu.com/security/CVE-2026-68332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix potential use-after-free in airoha_ppe_deinit() airoha_ppe_deinit() replaces the NPU pointer with NULL via rcu_replace_pointer() but does not wait for existing RCU readers to exit before calling ppe_deinit() and airoha_npu_put(). This can cause a use-after-free if a reader in an RCU read-side critical section still holds a reference to the NPU when it is freed. The init path (airoha_ppe_init) already calls synchronize_rcu() after rcu_assign_pointer(), but the deinit path introduced in commit 6abcf751bc08 (\"net: airoha: Fix schedule while atomic in airoha_ppe_deinit()\") omitted the matching barrier when switching from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer(). Add synchronize_rcu() before ppe_deinit() to ensure all existing RCU readers have completed before the NPU resources are released.", "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-68334", "url": "https://ubuntu.com/security/CVE-2026-68334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix io_thread race in rxrpc_wake_up_io_thread() rxrpc_wake_up_io_thread() checks local->io_thread before waking it, but then reloads the pointer for wake_up_process(). local->io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so the second load can see NULL even if the first load did not. Take a READ_ONCE() snapshot and use it for both the NULL check and the wake_up_process() call, as rxrpc_encap_rcv() already does.", "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-68341", "url": "https://ubuntu.com/security/CVE-2026-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix use after free in unlock_ovpn() unlock_ovpn() iterates over the release_list using llist_for_each_entry() and drops the peer reference inside the loop body via ovpn_peer_put(). If this drops the last reference, the peer is eventually freed. However, llist_for_each_entry() reads peer->release_entry.next in the loop advance expression, which runs after the body. By that time the peer may have already been freed, resulting in a use after free when advancing to the next list entry. Fix this by using llist_for_each_entry_safe(), which caches the next pointer before executing the loop body.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68342", "url": "https://ubuntu.com/security/CVE-2026-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: avoid putting unrelated P2P peer on socket release ovpn_peer_release_p2p() is called when an OVPN UDP socket is being destroyed. It checks the currently published P2P peer and releases it only if that peer still uses the socket being destroyed. A peer replacement can publish a new peer before the old UDP socket is destroyed. When the old socket destruction path runs afterwards, ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the new peer uses a different socket, the function takes the socket mismatch branch. That branch still calls ovpn_peer_put(peer). At this point, however, peer is the currently published replacement peer, not the peer associated with the socket being destroyed. Dropping its reference can free it while ovpn->peer still points to it, leading to later use-after-free accesses from the peer and socket cleanup paths. KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer object. In the reproducer, the object is allocated from ovpn_peer_new() via ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU callback processing. Observed access sites include ovpn_peer_remove(), ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn(). Fix this by returning from the socket mismatch branch without putting the peer.", "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-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-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-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-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-68356", "url": "https://ubuntu.com/security/CVE-2026-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: airoha: Prevent division by zero when clock frequency is zero clk_get_rate() can return 0 when the clock provider is not properly configured or the clock is unmanaged. The driver uses wdt_freq as a divisor directly in airoha_wdt_probe() to compute max_timeout and in airoha_wdt_get_timeleft() to compute the remaining time, which results in a division by zero. Add a check for wdt_freq == 0 in probe and return -EINVAL with dev_err_probe() to prevent the division by zero and provide a diagnostic message.", "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-68358", "url": "https://ubuntu.com/security/CVE-2026-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-kraken3) 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-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-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-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-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-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-68374", "url": "https://ubuntu.com/security/CVE-2026-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: sysfs: add lock to bos_descriptors_read() Add a lock to the function bos_descriptors_read(). This function accesses udev->bos, which could be simultaneously freed in usb_reset_and_verify_device(), a function that is commonly called in drivers all over the kernel.", "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-68378", "url": "https://ubuntu.com/security/CVE-2026-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions: - A pin is registered with two or more dpll devices (dpll_A, dpll_B) - The pin has ref_sync pairs with other pins - During unregistration of dpll_A's pins, a ref_sync partner pin is unregistered first, removing it from dpll_A->pin_refs - But since the partner pin is still registered with dpll_B, its dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT run and the partner stays in the pin's ref_sync_pins xarray - When the pin itself is then unregistered from dpll_A, the delete notification calls dpll_msg_add_pin_ref_sync() which finds the partner in ref_sync_pins, passes dpll_pin_available() (partner is still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A, partner) returns NULL because partner was already removed from dpll_A->pin_refs - The NULL priv pointer is passed to the driver's ref_sync_get callback, which dereferences it BUG: kernel NULL pointer dereference, address: 0000000000000034 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x] Call Trace: dpll_msg_add_pin_ref_sync+0xb8/0x200 dpll_cmd_pin_get_one+0x3b6/0x4b0 dpll_pin_event_send+0x72/0x140 __dpll_pin_unregister+0x5a/0x2b0 dpll_pin_unregister+0x49/0x70 Fix this by skipping ref_sync pins whose priv pointer cannot be resolved for the current dpll device.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68379", "url": "https://ubuntu.com/security/CVE-2026-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix TIME_WAIT socket reference leak on PSP policy failure Release the TIME_WAIT socket reference and jump to discard_it upon PSP policy failure in both IPv4 and IPv6 receive paths. This prevents a memory leak of tcp_tw_bucket structures.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68380", "url": "https://ubuntu.com/security/CVE-2026-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix use-after-free of mm_struct in job scheduler amdxdna_cmd_submit() stores current->mm in job->mm without holding any reference. aie2_sched_job_run() later access job->mm from the DRM scheduler worker thread. With only a raw pointer and no structural reference, the mm_struct can be freed before the scheduler runs the job. Fix this by calling mmgrab() to hold a structural mm_count reference for the lifetime of the job, paired with mmdrop() in every cleanup path.", "cve_priority": "high", "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-68384", "url": "https://ubuntu.com/security/CVE-2026-68384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits. - Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it. While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one. (cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68385", "url": "https://ubuntu.com/security/CVE-2026-68385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/checksum: Fix csum_partial() without vector facility Currently csum_partial() calls csum_copy() with copy=false and dst=NULL. On machines without the vector facility, csum_copy() falls back to cksm(dst, ...), causing the checksum to be calculated from address zero instead of the source buffer. The VX implementation already checksums data loaded from src. Make the fallback do the same by passing src to cksm().", "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-68387", "url": "https://ubuntu.com/security/CVE-2026-68387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: add locking for raw flags bitfield With commit 890e5198a6e5 (\"can: raw: use bitfields to store flags in struct raw_sock\") the formerly separate integer values have been integrated into a single bitfield. This led to a read-modify-write operation when changing a flag in raw_setsockopt() which now needs a locking to prevent concurrent access. Instead of adding a lock/unlock hell in each of the flag manipulations this patch introduces a wrapper for a new raw_setsockopt_locked() function analogue to the isotp_setsockopt[_locked]() approach in net/can/isotp.c [mkl: use Closes tag instead of Link]", "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-68393", "url": "https://ubuntu.com/security/CVE-2026-68393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: extend conn_hash lookup critical sections Using RCU-protected pointers outside the critical sections without refcount is incorrect and may result to UAF. Extend critical section to cover both hci_conn_hash lookup and use of the returned conn. Add surrounding rcu_read_lock() also when return value is not used, in preparation for RCU lockdep requirement to hci_lookup_le_connect(). This avoids concurrent deletion of the conn before we are done dereferencing it. Also, make sure to hold hdev->lock when accessing hdev->accept_list.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68394", "url": "https://ubuntu.com/security/CVE-2026-68394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update MGMT_OP_LOAD_CONN_PARAM queues conn_update_sync() when a single parameter update changes an existing LE central connection. The queued work currently stores a borrowed hci_conn_params entry from hdev->le_conn_params. A later LOAD_CONN_PARAM request can clear disabled parameters and free that entry before hci_cmd_sync_work() runs the queued callback. Do not keep the borrowed hci_conn_params pointer in queued work. Queue the hci_conn instead and hold a reference until the queued callback completes. When the work runs, revalidate that the connection is still present, look up the current hci_conn_params entry, and cancel the update if userspace removed that entry while the work was pending. Copy the interval values from the current params entry under hdev->lock, then drop the lock and keep using hci_le_conn_update_sync() to issue the update. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in conn_update_sync+0x2a/0xf0 [bluetooth] Read of size 1 at addr ffff88810c697126 by task kworker/u17:0/377 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 kasan_report+0xe0/0x110 conn_update_sync+0x2a/0xf0 [bluetooth] hci_cmd_sync_work+0x187/0x210 [bluetooth] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 Allocated by task 466: hci_conn_params_add+0xa6/0x240 [bluetooth] load_conn_param+0x4e1/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] Freed by task 474: kfree+0x313/0x590 hci_conn_params_clear_disabled+0x9b/0xc0 [bluetooth] load_conn_param+0x4bf/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth]", "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-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-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-68400", "url": "https://ubuntu.com/security/CVE-2026-68400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint memory access array and to comply with the FF-A spec instead of defaulting to `sizeof(struct ffa_mem_region)`. This requires moving `ffa_mem_region_additional_setup()` earlier in the setup flow. Also, add sanity checks to ensure the calculated descriptor offsets do not exceed `max_fragsize`.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68401", "url": "https://ubuntu.com/security/CVE-2026-68401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() Sashiko (locally) reports multiple out-of-bound issues in ffa_setup_and_transmit: 1) Writing ep_mem_access->reserved can write out of bounds for FFA versions < 1.2 as ffa_emad_size_get() returns 16 bytes in that case while reserved has an offset of 24. Instead of zeroing fields, memset the struct to zero first based on the FFA version. 2) Make sure there is enough size to write constituents. While at it, convert the only sizeof() in the driver that uses a type instead of variable.", "cve_priority": "high", "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-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-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-68409", "url": "https://ubuntu.com/security/CVE-2026-68409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: defer link RX stats percpu free to RCU sta_remove_link() frees a removed MLO link's RX stats percpu buffer right away, but defers only the link container to RCU: \tsta_info_free_link(&alloc->info); \tkfree_rcu(alloc, rcu_head); The RX fast path reads link_sta under rcu_read_lock and writes the percpu stats. A reader that resolved link_sta before the removal keeps the pointer. The container stays alive from the kfree_rcu, so the read still works. But the percpu block it points to is already freed. This needs uses_rss. That is when pcpu_rx_stats exists. The full STA teardown frees the deflink stats only after synchronize_net(). The link removal path had no such barrier. The race is hard to win in practice, but the free should still wait for RCU. Free the link together with its data from a single RCU callback, so the percpu block is reclaimed only after readers drain.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20: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-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-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-68412", "url": "https://ubuntu.com/security/CVE-2026-68412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan() If the test against IEEE80211_MAX_SSID_LEN fails, then 'creq' leaks. Use the existing error handling path to fix it.", "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-64566", "url": "https://ubuntu.com/security/CVE-2026-64566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags() When iptfs_skb_add_frags() copies frag references from the source frag walk into a new SKB, it increments the page reference count via __skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the destination SKB's skb_shinfo->flags. If the source SKB carries shared frags (e.g. from a page-pool backed receive path), the new inner SKB will appear to ESP as having privately owned frags. A subsequent esp_input() call for a nested transport-mode SA then takes the no-COW fast path and decrypts in place, writing over pages that are still referenced by the outer IPTFS SKB. This causes kernel-visible memory corruption and can trigger a panic. All other frag-transfer helpers in the kernel (skb_try_coalesce, skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this convention by setting the flag inside the loop immediately after __skb_frag_ref() and nr_frags++, so every exit path that attaches a frag unconditionally propagates SKBFL_SHARED_FRAG.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68415", "url": "https://ubuntu.com/security/CVE-2026-68415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear mode callbacks after failed mode setup xfrm_state_gc_task can run long after a failed IPTFS state setup. In the reproduced case, __xfrm_init_state() cached x->mode_cbs, IPTFS setup returned -ENOMEM before publishing mode_data, and the temporary module reference from xfrm_get_mode_cbs() was dropped immediately. The dead state then kept x->mode_cbs until deferred GC ran after xfrm_iptfs had been unloaded. Clear x->mode_cbs when mode init or clone fails before publishing mode_data. Those states never installed mode-specific state or the long-term IPTFS module pin, so deferred GC has nothing mode-specific to destroy and must not retain a callback table pointer past the temporary lookup reference. The buggy scenario involves two paths, with each column showing the order within that path: failed setup path: 1. cache x->mode_cbs 2. mode setup fails before mode_data 3. drop the temporary module ref 4. dead state keeps x->mode_cbs cached GC/unload path: 1. xfrm_state_put() queues GC work 2. xfrm_iptfs unloads later 3. xfrm_state_gc_task runs 4. GC dereferences stale x->mode_cbs This also covers the failed clone path where clone_state() returns before publishing mode_data. Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y failslab_stacktrace_filter matched xfrm_iptfs frames ack_error=-12 FAULT_INJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrm_state_gc_task RIP: xfrm_state_gc_task+0x142/0x650 Modules linked in: esp4_offload xfrm_user [last unloaded: xfrm_iptfs] Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68418", "url": "https://ubuntu.com/security/CVE-2026-68418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent user-triggered null deref on QP create Previously, the user QP creation path would only attempt to populate iwqp->iwpbl if the user-provided req.user_wqe_bufs field was non-zero. The problem is that iwqp->iwpbl is unconditionally dereferenced later on in irdma_setup_virt_qp. While there was a check for iwqp->iwpbl != NULL, this check would only occur if req.user_wqe_bufs was non-zero. The end result is that a user could send a zero user_wqe_bufs value and trigger a null ptr deref. Fix this by unconditionally calling irdma_get_pbl and bailing if it fails, similar to the CQ and SRQ paths.", "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-68420", "url": "https://ubuntu.com/security/CVE-2026-68420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: reject optional IPTFS templates in outbound policies syzbot reported a stack-out-of-bounds read in xfrm_state_find() which flows from xfrm_tmpl_resolve_one(). Commit 3d776e31c841 (\"xfrm: Reject optional tunnel/BEET mode templates in outbound policies\") disallowed optional tunnel and BEET in outbound policies to prevent this. Later when IPTFS added, it was not covered by that fix and can still trigger the out-of-bounds read; Extend the check to disallow optional IPTFS in outbound policies as well. IPTFS should be identical to tunnel mode. IN and FWD policies are not affected: xfrm_tmpl_resolve_one() is only reachable via the outbound path. Reproducer, before: ip link add dummy0 type dummy ip link set dummy0 up ip addr add 10.1.1.1/24 dev dummy0 ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 mode transport ping -W 1 -c 1 10.1.1.2 PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data. [ 64.168420] ================================================================== [ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844 [ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full) [ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 64.169977] Call Trace: [ 64.169977] [ 64.169977] dump_stack_lvl+0x47/0x70 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] print_report+0x152/0x4b0 [ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0 [ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20 [ 64.169977] ? __virt_addr_valid+0x21b/0x230 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] kasan_report+0xa8/0xd0 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm_dst_hash+0x24/0xc0 [ 64.169977] xfrm_state_find+0xa2d/0x2f90 [ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570 [ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10 [ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 64.169977] ? kernel_text_address+0x5b/0x80 [ 64.169977] ? __kernel_text_address+0xe/0x30 [ 64.169977] ? unwind_get_return_address+0x5e/0x90 [ 64.169977] ? arch_stack_walk+0x8c/0xe0 [ 64.169977] xfrm_tmpl_resolve+0x130/0x200 [ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10 [ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110 [ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10 [ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310 [ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80 [ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10 [ 64.169977] ? ip_route_output_key_hash+0xc6/0x110 [ 64.169977] ? kasan_save_track+0x10/0x30 [ 64.169977] xfrm_lookup_route+0x18/0xe0 [ 64.169977] ip4_datagram_release_cb+0x4c9/0x530 [ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10 [ 64.169977] ? do_raw_spin_lock+0x71/0xc0 [ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 64.169977] release_sock+0xb0/0x170 [ 64.169977] udp_connect+0x43/0x50 [ 64.169977] __sys_connect+0xa6/0x100 [ 64.169977] ? alloc_fd+0x2e9/0x300 [ 64.169977] ? __pfx___sys_connect+0x10/0x10 [ 64.169977] ? preempt_latency ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68421", "url": "https://ubuntu.com/security/CVE-2026-68421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx() put_prev_task_scx() warns when a runnable task drops to a lower sched_class without SCX_OPS_ENQ_LAST, on the assumption that balance_one() would have kept it running. Core scheduling breaks that: a forced-idle SMT sibling reschedules through the core_pick fast path in pick_next_task(), which skips pick_task_scx() and thus balance_one(), so a runnable task can drop to idle with ENQ_LAST unset. Gate the warning on sched_cpu_cookie_match(): a cookie mismatch means core scheduling forced the idle, while a match (or core scheduling off) still catches a genuine missing-ENQ_LAST drop.", "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-68426", "url": "https://ubuntu.com/security/CVE-2026-68426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix stale skb->prev after async crypto steals a GSO segment skb_gso_segment() leaves the segment list head with ->prev pointing at the last segment, an invariant validate_xmit_skb_list() relies on when it sets its tail pointer (tail = skb->prev). When validate_xmit_xfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validate_xmit_skb_list() later does tail->next = skb, writing through that stale pointer -- a use-after-free. Repoint skb->prev at the last retained segment before returning.", "cve_priority": "critical", "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-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-2023-20585", "url": "https://ubuntu.com/security/CVE-2023-20585", "cve_description": "Insufficient checks of the RMP on host buffer access in IOMMU may allow an attacker with privileges and a compromised hypervisor to trigger an out of bounds condition without RMP checks, resulting in a potential loss of confidential guest integrity.", "cve_priority": "low", "cve_public_date": "2026-04-16 19:16:00 UTC" }, { "cve": "CVE-2026-68364", "url": "https://ubuntu.com/security/CVE-2026-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix ISM dc_lock deadlock during suspend [Why] System hang observed during suspend/resume while video is playing. amdgpu_dm_ism_disable() is called under dc_lock and waits for ISM delayed work via disable_delayed_work_sync(). The work handlers themselves take dc_lock, producing an ABBA deadlock when a worker is in flight at suspend time. [How] Split the disable path into two phases with opposite locking contracts: 1. amdgpu_dm_ism_disable() -- quiesces workers, must NOT hold dc_lock. 2. amdgpu_dm_ism_force_full_power() (new) -- drives the ISM FSM back to FULL_POWER_RUNNING, must hold dc_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72064", "url": "https://ubuntu.com/security/CVE-2026-72064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Sync page pool RX frags for CPU MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack.", "cve_priority": "medium", "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-72098", "url": "https://ubuntu.com/security/CVE-2026-72098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: fix buffer overflow in FEC calculation There's a buffer overflow in dm-verity-fec: if (neras && *neras <= v->fec->roots) \tfio->erasures[(*neras)++] = i; This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72248", "url": "https://ubuntu.com/security/CVE-2026-72248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: support IPIP tunnel with direct xmit The combination of IPIP tunnel with direct xmit, eg. bridge device, breaks because no dst_entry is provided to check the skb headroom and to set the iph->frag_off field. This leads to invalid dst usage and can trigger a crash in the tunnel transmit path. Fix this by moving dst_cache and dst_cookie out of the runtime union so that they can be shared by neighbour, xfrm, and direct tunnel flows. For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve route state in these shared fields and release it through the common dst release path. Since dst_entry is now available to the three supported xmit modes and dst_release() already deals with NULL dst, remove the xmit type check in nft_flow_dst_release(). Moreover, skip the check if the dst entry is NULL in nf_flow_dst_check() which is now the case for the direct xmit case. Based on patch from Rein Wei .", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72249", "url": "https://ubuntu.com/security/CVE-2026-72249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: use dst in this direction when pushing IPIP header When pushing the IPIP header, the route of the other direction is used to calculate the headroom, use the route in this direction. Accessing the other tuple to set the IP source and destination is fine because this tuple does not provide such information to avoid storing redundant information. However, this tuple already provides the dst for this direction, this went unnoticed because this bug affects headroom and iph->frag_off only at this stage.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72287", "url": "https://ubuntu.com/security/CVE-2026-72287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the \"normal\" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a \"late\" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72329", "url": "https://ubuntu.com/security/CVE-2026-72329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/liquidio: drop cached VF pci_dev LUT The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST. Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72355", "url": "https://ubuntu.com/security/CVE-2026-72355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix barriering when walking subrequest list Fix the barriering used when walking the subrequest list in retry as there's a possibility of seeing a subreq that's just been added by the application thread.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72412", "url": "https://ubuntu.com/security/CVE-2026-72412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/mm: Fix handling of _PAGE_UNUSED pte bit The _PAGE_UNUSED softbit should not really be lying around. Its sole purpose is to signal to try_to_unmap_one() and try_to_migrate_one() that the page can be discarded instead of being moved / swapped. KVM has no way to know why a page is being unmapped, so it sets the bit on userspace ptes corresponding to unused guest pages every time they get unmapped. KVM has no reasonable way to clear the bit once the page is in use again. While set_ptes() checks and clears the bit, other paths that set new ptes did not. This led to used pages being thrown out as if they were unused, causing guest corruption. Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in set_pte(), i.e. whenever a present pte is getting set. The check in set_ptes() is then redundant and can be removed. Also fix gmap_helper_try_set_pte_unused() to only set the bit if the pte is present; the _PAGE_UNUSED bit is only defined for present ptes and thus should not be set for non-present ptes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72417", "url": "https://ubuntu.com/security/CVE-2026-72417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto() Add sanity check for iph->ihl field in nf_flow_ip4_tunnel_proto() before using it to compute the header size, avoiding out-of-bounds access with malformed IP headers. While at it, use iph->protocol instead of the hardcoded IPPROTO_IPIP constant when setting ctx->tun.proto and reference ctx->tun.hdr_size when updating ctx->offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72442", "url": "https://ubuntu.com/security/CVE-2026-72442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: fix and simplify IP6IP6 tunnel handling Fix nf_flow_ip6_tunnel_proto() to use pskb_may_pull() instead of skb_header_pointer() to ensure the outer IPv6 header is in the skb headroom, which is required for subsequent packet processing. Move ctx->offset update inside the IPPROTO_IPV6 conditional block since it should only be adjusted when an IP6IP6 tunnel is actually detected. Simplify the rx path by removing ipv6_skip_exthdr() and checking ip6h->nexthdr directly, as the flowtable fast path only handles simple IP6IP6 encapsulation without extension headers. Drop the tunnel encapsulation limit destination option support from the tx path to match, since the rx path no longer handles extension headers. Remove the encap_limit parameter from nf_flow_offload_ipv6_forward(), nf_flow_tunnel_ip6ip6_push() and nf_flow_tunnel_v6_push(), along with the ipv6_tel_txoption struct and related headroom/MTU adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72463", "url": "https://ubuntu.com/security/CVE-2026-72463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix dev use-after-free in xfrm async resumption xfrm async resumption hold skb->dev refcnt until after transport_finish. However, xfrm_rcv_cb may modify skb->dev to tunnel dev without taking device reference, such as vti_rcv_cb. The subsequent async resumption will decrement the tunnel device's reference count, which lead to uaf of tunnel dev and refcnt leak of orig dev as below: unregister_netdevice: waiting for vti1 to become free. Usage count = -2 Stash the original skb->dev to fix refcnt imbalance. The new skb->dev set by xfrm_rcv_cb can race with device teardown. Extend rcu protection over xfrm_rcv_cb and transport_finish to prevent races.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72477", "url": "https://ubuntu.com/security/CVE-2026-72477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: call _ntfs_bad_inode() when failing to rename It is safe to call _ntfs_bad_inode on live inodes since: commit 519b078998ce (\"fs/ntfs3: Exclude call make_bad_inode for live nodes.\") The WARN_ON was added when it wasn't safe by: commit d99208b91933 (\"fs/ntfs3: cancle set bad inode after removing name fails\") Replace the WARN_ON with a call to _ntfs_bad_inode() to prevent further operations on the inconsistent inode.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72493", "url": "https://ubuntu.com/security/CVE-2026-72493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: serialize netif_running() check in enqueue_to_backlog() Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup(). The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit). Commit e9e4dd3267d0 (\"net: do not process device backlog during unregistration\") introduced a lockless netif_running() check in enqueue_to_backlog() to prevent queuing packets to an unregistering device. However, this creates a TOCTOU race window. A lockless transmitter (like veth_xmit) can pass the check before dev_close() clears IFF_UP. If the transmitter is then delayed, flush_all_backlogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed. Fix this by moving the netif_running() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netif_running() after the flush/close completes (so it gets dropped).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72494", "url": "https://ubuntu.com/security/CVE-2026-72494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Replace waitqueue and flag with completion The driver previously used a waitqueue along with an explicit request_done flag, but without proper barriers around request_done. An earlier patch by Gui-Dong Han attempted to fix this by adding the missing memory barriers. Rather than adding the barriers, this patch replaces the waitqueue+flag with a completion, which is designed for this exact purpose.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72496", "url": "https://ubuntu.com/security/CVE-2026-72496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Proper rollback if the ioremap fails bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74269", "url": "https://ubuntu.com/security/CVE-2026-74269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt: fix head underflow on XDP head-grow The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free. The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with this commit applied causes the test to run successfully to completion. The other rx_skb_func implementations don't have this issue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74350", "url": "https://ubuntu.com/security/CVE-2026-74350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate fast symlink target during inode read ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment. A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer. Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated. This keeps malformed fast symlinks from reaching the read path. Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x19f/0x330 (?:?) kasan_report+0xe0/0x110 (?:?) kasan_check_range+0x105/0x1b0 (?:?) __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72495", "url": "https://ubuntu.com/security/CVE-2026-72495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid repeated requests to allocate WC pages Applications can request multiple WC pages for the same ucontext. As of now, only 1 WC page per ucontext is supported. Add a lock to avoid concurrent access and a check to fail repeated requests. Also, if the mmap entry insert fails for the WC, free the Doorbell page index mapped for the WC page.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72501", "url": "https://ubuntu.com/security/CVE-2026-72501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Initialize dpi variable to zero dpi is initialized only for BNXT_RE_ALLOC_WC_PAGE, but copied for all the cases. So initialize the dpi to 0.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72278", "url": "https://ubuntu.com/security/CVE-2026-72278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Re-translate VNCR before injecting abort KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor updates and MMU faults.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68083", "url": "https://ubuntu.com/security/CVE-2026-68083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix path resolution in ksmbd_vfs_kern_path_create The SMB2 open lookup is rooted at the share with LOOKUP_BENEATH, but the create/mkdir/hardlink sink is not: ksmbd_vfs_kern_path_create() builds an absolute path with convert_to_unix_name() and resolves it from AT_FDCWD via start_creating_path(), so a \"..\" component is walked from the real filesystem root and escapes the export. An authenticated client races a missing path component so the rooted open lookup returns -ENOENT (taking the create branch) while the same component is present (a directory) when the create walk runs; the create then resolves \"..\" out of the share. Root the create walk at the share like the lookup and rename paths already are: resolve the parent with vfs_path_parent_lookup(..., LOOKUP_BENEATH, &share_conf->vfs_path) and create the final component with start_creating_noperm(). convert_to_unix_name() then has no callers and is removed.", "cve_priority": "high", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-68457", "url": "https://ubuntu.com/security/CVE-2026-68457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use opener credentials for FSCTL mutations SET_SPARSE, SET_ZERO_DATA and SET_COMPRESSION operate on an open SMB handle but call VFS xattr, fallocate or fileattr helpers with the current ksmbd worker credentials. Those helpers can revalidate inode permissions, ownership and LSM policy independently of the SMB handle access mask. Run each operation with the credentials captured in the target file when the handle was opened. Keep credential handling local to these single-file FSCTLs rather than applying session credentials to the complete IOCTL handler, which also contains handle-less and multi-handle operations.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72041", "url": "https://ubuntu.com/security/CVE-2026-72041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: use sk_msg_free_partial to fix partial send sk_msg_free_partial() ensures consistency of the skmsg at every iteration, without having to manually handle uncharges and offsets. This simplifies the code, and fixes some bugs in skmsg accounting when we don't send the full contents.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72046", "url": "https://ubuntu.com/security/CVE-2026-72046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing.", "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-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21: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-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72137", "url": "https://ubuntu.com/security/CVE-2026-72137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: nat_keepalive: avoid double free on send error nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6 send helper reports an error. That cleanup is only correct before the skb is handed to the output path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the networking stack may already have consumed the skb before returning an error, so freeing it again is unsafe. Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4() and nat_keepalive_send_ipv6(), where the caller still owns the skb, and keep nat_keepalive_send() responsible only for family dispatch and the unsupported-family cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72139", "url": "https://ubuntu.com/security/CVE-2026-72139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: defer md5sig_info kfree past RCU grace period in tcp_connect The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: \tif (needs_md5) { \t\ttcp_ao_destroy_sock(sk, false); \t} else if (needs_ao) { \t\ttcp_clear_md5_list(sk); \t\tkfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); \t} Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with tcp-diag]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72191", "url": "https://ubuntu.com/security/CVE-2026-72191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: validate split-point offset in indx_insert_into_buffer indx_insert_into_buffer() computes used = used1 - to_copy - sp_size; memmove(de_t, Add2Ptr(sp, sp_size), used - le32_to_cpu(hdr1->de_off)); where sp and sp_size come from hdr_find_split(). hdr_find_split() walks entries by le16_to_cpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFS_DE). index_hdr_check(), the on-load gatekeeper, only validates header-level fields (used, total, de_off) and does not walk per-entry sizes. A crafted NTFS image whose leaf INDEX_HDR reports used == total but contains one interior NTFS_DE with size = 0xFFF0 therefore passes validation, descends to indx_insert_into_buffer() through the ntfs_create() -> indx_insert_entry() path, and makes hdr_find_split() return an sp whose sp_size (0xFFF0) greatly exceeds the remaining bytes in the buffer. The u32 subtraction underflows and the memmove count becomes a near-4-GiB value, producing an out-of-bounds kernel write that corrupts adjacent allocations and panics the kernel. Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a single 'touch' inside the mounted directory; crash site resolves to fs/ntfs3/index.c at the memmove. Trigger requires only local mount of an attacker-supplied filesystem image (USB, loopback, or removable media auto-mount). Reject the split whenever the chosen sp plus its declared size already extends past hdr1->used. This is the minimal fix; it preserves the existing hdr_find_split() contract and relies on the same out: cleanup path as the pre-existing error returns. A prior OOB read in the very same indx_insert_into_buffer() memmove was fixed in commit b8c44949044e (\"fs/ntfs3: Fix OOB read in indx_insert_into_buffer\") by tightening hdr_find_e(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdr_find_split(), not hdr_find_e(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72217", "url": "https://ubuntu.com/security/CVE-2026-72217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing xdr_buf_to_bvec() writes a bio_vec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it. rq_bvec, the array passed by nfsd_vfs_write(), is allocated to exactly rq_maxpages entries with no slack. The OOB store can land in adjacent slab memory; the bv_len and bv_offset fields written there are derived from client-supplied RPC payload sizes. Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72220", "url": "https://ubuntu.com/security/CVE-2026-72220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp->rq_procinfo->pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72221", "url": "https://ubuntu.com/security/CVE-2026-72221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: wait for in-flight TLS handshake callback when cancel loses race When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed. The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result. If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue. If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed. Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed to fire because handshake_complete() invokes svc_tcp_handshake_done() unconditionally once it has set HANDSHAKE_F_REQ_COMPLETED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72222", "url": "https://ubuntu.com/security/CVE-2026-72222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: pin svc_xprt across the asynchronous TLS handshake callback svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of(). Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done. The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry. Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all(). [cel: rewrote commit message to describe the actual change]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72277", "url": "https://ubuntu.com/security/CVE-2026-72277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the simpler thing for now and just reject everything that isn't memory.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72279", "url": "https://ubuntu.com/security/CVE-2026-72279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR KVM currently maps the L1 VNCR into the host stage-1 by relying entirely on the permissions of the guest stage-1. At the same time, it is entirely possible that the backing PFN is read-only (e.g. RO memslot), meaning that the L1 VNCR should use at most a read-only mapping. Cache the writability of the PFN in the VNCR TLB and use it to constrain the resulting fixmap permissions. Promote VNCR permission faults to an SEA in the case where the guest attempts to write to a read-only endpoint. Conveniently, this also plugs a page leak found by Sashiko [*] resulting from the early return for a read-only PFN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72288", "url": "https://ubuntu.com/security/CVE-2026-72288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling Hyunwoo Kim reports some really bad races should the following situation occur: - LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C If the last two race nicely enough, vgic_prune_ap_list() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows. The fix is two-fold: - Before dropping the irq and ap_list locks, take a reference on the irq - Do not try to handle migration of the pending bit: there is no expectation that this state is retained, as per the architecture With that, we're sure that the interrupt is still around, and we safely remove it from the AP list as it has no target at this stage (unless another interrupt fires, but that's another story).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "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-72317", "url": "https://ubuntu.com/security/CVE-2026-72317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: pin upper rpc_clnt across the TLS connect_worker The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt. The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported. Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one. The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72318", "url": "https://ubuntu.com/security/CVE-2026-72318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate DFS referral string offsets parse_dfs_referrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server. Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative max_len is then passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds. Validate each string offset before deriving the string pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72320", "url": "https://ubuntu.com/security/CVE-2026-72320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_lookup: fix catchall element handling with inverted lookups nft_lookup_eval() decides whether a lookup matched (`found`) from the direct set lookup and priv->invert before falling back to the catchall element used by interval sets (e.g. nft_set_rbtree) for the open-ended default range. Since `found` is never recomputed after `ext` is replaced by the catchall lookup, inverted lookups (NFT_LOOKUP_F_INV, \"!= @set\") can wrongly match or wrongly skip the catchall element, producing the wrong verdict. Fold the catchall lookup into `ext` before computing `found`, matching the order already used by nft_objref_map_eval().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72366", "url": "https://ubuntu.com/security/CVE-2026-72366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_create_write_req() to handle async cache object creation netfs_create_write_req() will skip caching if the fscache cookie is disabled, but this is a problem because async cache object creation might not have got far enough yet that has been enabled - thereby causing the call to fscache_begin_write_operation() to be skipped. Fix this by removing the checks on the cookie and delegating this to fscache_begin_write_operation().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72381", "url": "https://ubuntu.com/security/CVE-2026-72381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of fp->owner.name in durable handle owner check Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d (\"ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd\") made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized. BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8 Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72393", "url": "https://ubuntu.com/security/CVE-2026-72393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: don't cache shinfo across skb realloc fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb including the shared info. We can't use the pointer calculated before the call. BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0 Read of size 4 at addr ff110000262edd98 by task swapper/5/0 Call Trace: fbnic_tx_lso.isra.0+0x668/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 Allocated by task 8653: __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xcc/0x6c0 sock_alloc_send_pskb+0x327/0x3f0 __ip_append_data+0x188b/0x47a0 ip_make_skb+0x24a/0x300 udp_sendmsg+0x14d2/0x21e0 Freed by task 0: kfree+0x123/0x5a0 pskb_expand_head+0x36c/0xfa0 fbnic_tx_lso.isra.0+0x500/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 sch_direct_xmit+0x25b/0x1100 The buggy address belongs to the object at ff110000262edc40 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 344 bytes inside of freed 640-byte region [ff110000262edc40, ff110000262ede", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72398", "url": "https://ubuntu.com/security/CVE-2026-72398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: add INIT verification after cookie unpacking In SCTP handshake, the INIT chunk is initially processed by the server and embedded into the cookie carried in INIT-ACK. The client then returns this cookie via COOKIE-ECHO, where the server unpacks it and reconstructs the original INIT chunk. When cookie authentication is enabled, the cookie contents are protected against tampering, so reusing the unpacked INIT without re-verification is safe. However, when cookie authentication is disabled, the reconstructed INIT can no longer be trusted. In this case, the INIT must be explicitly validated after unpacking to avoid processing potentially tampered data. Add sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO processing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook()) when cookie_auth_enable is disabled. On failure, the new association is freed and the packet is discarded. Also tighten cookie validation in sctp_unpack_cookie() by verifying the embedded chunk type is SCTP_CID_INIT before treating it as an INIT chunk. Finally, update sctp_verify_init() to validate parameter bounds using the actual embedded INIT length instead of chunk->chunk_end, since the INIT stored in COOKIE-ECHO may not span the entire chunk buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72399", "url": "https://ubuntu.com/security/CVE-2026-72399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: check the number of BDs needed for xdp_frame The size of xdp_redirect_arr array is ENETC_MAX_SKB_FRAGS. However, the number of fragments contained in xdp_frame may be greater than or equal to ENETC_MAX_SKB_FRAGS, which will cause the access to xdp_redirect_arr to be out of bounds.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72429", "url": "https://ubuntu.com/security/CVE-2026-72429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix type confusion of dst_entry IOAM uses a dummy dst_entry(null_dst) to mark that the destination should not be changed after the transformation. This dst is stored in the IOAM lwt state and may be passed to dst_cache_set_ip6(). However, the IPv6 dst cache path eventually calls rt6_get_cookie(), which treats the dst_entry as part of a struct rt6_info. Since the null_dst was embedded directly as a struct dst_entry in struct ioam6_lwt, this resulted in an invalid cast and rt6_get_cookie() reading fields from the wrong object. In practice, the wrong cookie is not used while dst->obsolete is zero, but rt6_get_cookie() may also access per-cpu value when rt->sernum is zero. In this case, rt->sernum aliases ioam6_lwt::cache::reset_ts, which can become zero, making this a potential invalid pointer access. Fix this by embedding a full struct rt6_info for the dummy IPv6 route and passing its dst member to the dst APIs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72436", "url": "https://ubuntu.com/security/CVE-2026-72436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash types Sashiko pointed out that there are a few lockless RCU readers using test_bit() which is a relaxed atomic operation and provides no memory barrier guarantees. Use test_bit_acquire() instead where the operation may run parallel with add/del/gc, i.e. is not one from the next cases - protected by region lock - in a set destroy phase - in a new/temporary set creation phase", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72451", "url": "https://ubuntu.com/security/CVE-2026-72451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix xfrm state cache insertion race The xfrm input state cache insertion code checks the validity of the state before acquiring the global xfrm_state_lock. Thus it's possible for someone else to kill the state after it passed the validity check, and then the insertion will add the dead state to the cache. Fix this by moving the validity check inside the lock. This entire function is called on the input path, where BH must be off (e.g., the caller of this function xfrm_input acquires its spinlocks without disabling BH). So there is no need to disable BH here or take the RCU read lock. Remove both and replace them with an assertion that trips if BH is accidentally enabled on some future calling path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72472", "url": "https://ubuntu.com/security/CVE-2026-72472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: use nfsi->rwsem to protect traversal of the file lock list Lingfeng identified a bug and suggested two solutions, but both appear to have issues. Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case. Furthermore, after commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk. Regarding the bug fixed by commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), it has been resolved after commit 0460253913e5 (\"NFSv4: nfs4_do_open() is incorrectly triggering state recovery\") because all slots are drained before calling nfs4_do_reclaim, which prevents concurrent stateid changes along this path. Also, nfs_delegation_claim_locks does not cause this concurrency either since when _nfs4_proc_setlk is called with NFS_DELEGATED_STATE, no RPC is sent, so nfs4_lock_done is not called. Therefore, nfs4_lock_delegation_recall from nfs_delegation_claim_locks is the first time the stateid is set.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72473", "url": "https://ubuntu.com/security/CVE-2026-72473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decouple req recycling from RPC completion rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer. Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off. The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry. Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied. Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected. Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released. The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74310", "url": "https://ubuntu.com/security/CVE-2026-74310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/net: complete zerocopy ubufs only once vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74345", "url": "https://ubuntu.com/security/CVE-2026-74345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix endpoint/socket association handling Disassociating a socket from an endpoint via siw_socket_disassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within. This fixes a: BUG: KASAN: slab-use-after-free in siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1053 drivers/infiniband/sw/siw/siw_cm.c:1075) which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74361", "url": "https://ubuntu.com/security/CVE-2026-74361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: fix FDP fdpcidx bounds check The fdpcidx bounds check sets n = NUMFDPC + 1 but used > instead of >=, incorrectly accepting fdp_idx when it equals n (i.e. NUMFDPC + 1).", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74401", "url": "https://ubuntu.com/security/CVE-2026-74401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix add msg handle in send_queue ordered In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as \"before(mh->seq, seq)\" will stop to check for older sequence numbers that are ordered in the tail of \"node->send_queue\". The side effects of not having it correct ordered regarding \"before(mh->seq, seq)\" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74406", "url": "https://ubuntu.com/security/CVE-2026-74406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74428", "url": "https://ubuntu.com/security/CVE-2026-74428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix double unlock in rxrpc_recvmsg() Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74433", "url": "https://ubuntu.com/security/CVE-2026-74433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix UAF in rxgk_issue_challenge() Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74434", "url": "https://ubuntu.com/security/CVE-2026-74434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Don't move a peeked OOB message onto the pending queue rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so only unlink it from recvmsg_oobq and then move it onto pending_oobq or free it when the message is actually consumed.", "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-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-74439", "url": "https://ubuntu.com/security/CVE-2026-74439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clear Present bit before tearing down scalable-mode context entry device_pasid_table_teardown() zeroes the 128-bit scalable-mode context entry with context_clear_entry() while the Present bit is still set. This creates a window where the hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behavior or spurious faults. The context-cache invalidation is issued only after the entry has been zeroed, and intel_pasid_free_table() then frees the PASID directory pages, so the IOMMU can keep walking a stale Present=1 entry that points at freed memory. While x86 provides strong write ordering, the compiler may reorder the two 64-bit writes to the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Commit c1e4f1dccbe9d (\"iommu/vt-d: Clear Present bit before tearing down context entry\") fixed this exact pattern in domain_context_clear_one() and the copied-context path, but device_pasid_table_teardown() was not converted. Align it with the \"Guidance to Software for Invalidations\" in the VT-d spec, Section 6.5.3.3, using the same ownership handshake as the sibling fix: clear only the Present bit, flush it to the IOMMU, perform the context-cache invalidation, and only then zero the rest of the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2165483, 2165484, 2165407, 2166547, 2166443, 2166356, 2165872, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165407, 2165040, 2161748, 2163508, 2163214, 2162904, 2162045, 2164967, 2160082, 2164504, 2156316, 2164716, 2164516, 2163375, 2162803, 2163062, 2132119, 2163293, 2160200, 2158858, 2162704, 2162695, 2164666, 2164666, 2163121 ], "changes": [ { "cves": [ { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-68105", "url": "https://ubuntu.com/security/CVE-2026-68105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix kernel panic during driver load failure Avoid kernel panic if MES init fails during driver load. The KIQ ring is falsely marked as ready as ASICs that use MES, KIQ is owned by MES. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] Call Trace: gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280 __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53 (cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68109", "url": "https://ubuntu.com/security/CVE-2026-68109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68114", "url": "https://ubuntu.com/security/CVE-2026-68114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit e4d99e04b2e9b13b97d3b17804c735f62689db23)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68431", "url": "https://ubuntu.com/security/CVE-2026-68431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate minimum PDU size for transform requests The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68138", "url": "https://ubuntu.com/security/CVE-2026-68138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: serialize qdisc_rtab_list against concurrent get/put qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68082", "url": "https://ubuntu.com/security/CVE-2026-68082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix two unsafe bare decodes in decode_lockers() decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-08 10:16:00 UTC" }, { "cve": "CVE-2026-68159", "url": "https://ubuntu.com/security/CVE-2026-68159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68163", "url": "https://ubuntu.com/security/CVE-2026-68163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_vma_mapped: fix device-private PMD handling Commit 65edfda6f3f2 (\"mm/rmap: extend rmap and migration support device-private entries\") introduced the concept of device-private PMD entries, but did not correctly update the rmap walk code to account for them. As a result, when page_vma_mapped_walk() encounters device-private PMD entries, it takes no action other than to acquire the PMD lock and exit. However this is highly problematic for two reasons - firstly, device private entries possess a PFN so check_pmd() needs to be called to ensure an overlapping PFN range. Secondly, and more importantly, if PVMW_MIGRATION is set the caller assumes the returned entry is a migration entry, resulting in memory corruption when the caller tries to interpret the device private entry as such. In addition, commit 146287290023 (\"mm/huge_memory: implement device-private THP splitting\") allowed device private PMDs to be split like THP mappings, but again did not update this code path. As a result, we might race a PMD split prior to acquiring the PMD lock. This patch addresses all of these issues by invoking check_pmd(), ensuring PMVW_MIGRATION is not set and checks whether a split raced us we do for PMD THP and migration entries. Instead of checking for a subset of the cases after taking the pmd_lock(), put device-private along with pmd_trans_huge() and pmd_is_migration_entry(). Also remove thp_migration_supported() as it is already guarded by pmd_is_migration_entry(). [akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68166", "url": "https://ubuntu.com/security/CVE-2026-68166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: prevent registration of special VMAs Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68170", "url": "https://ubuntu.com/security/CVE-2026-68170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix stale skb->sk reference on subflow close The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68177", "url": "https://ubuntu.com/security/CVE-2026-68177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Delay module ref count for \"enable_event\" trigger Triggers are now delayed from freeing, but can still be triggered until after the RCU grace period has ended. The freeing of the enable_event data is put into the private_data_free() callback, but the put of the module refcount is done immediately. It is possible that if a module is removed that has an event that would enable (or disable) it is still active, it can read the data of the module after it is removed causing a use-after-free bug. Move the trace_event_put_ref() that releases the module into the delayed callback so that the module can not be removed until any reference to its events are finished.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68191", "url": "https://ubuntu.com/security/CVE-2026-68191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix NULL pointer dereference in rhash table destroy When unbinding the ath12k driver, kernel NULL pointer dereferences occur in irq_work_sync() called from rhashtable_destroy(). Two hash tables are affected: 1. ath12k_link_sta hash table in ath12k_base 2. ath12k_dp_link_peer hash table in ath12k_dp The issue happens because the destroy functions are called unconditionally in cleanup paths, but the hash tables are only initialized late in their respective init functions. If the device was never fully started or if the init functions failed before initializing the hash tables, the pointers will be NULL. The issues are always reproducible from a VM because the MSI addressing initialization is failing. Call trace for ath12k_link_sta_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_link_sta_rhash_tbl_destroy+0x19/0x40 [ath12k] ath12k_core_stop+0xe/0x80 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Call trace for ath12k_dp_link_peer_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_dp_link_peer_rhash_tbl_destroy+0x29/0x50 [ath12k] ath12k_dp_cmn_device_deinit+0x21/0x140 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Fix this by adding NULL checks before calling rhashtable_destroy() in both destroy functions. The NULL check approach was chosen because the rhashtable pointer serves as the initialization state indicator. The init can fail at various points, leaving some components uninitialized. Checking the pointer directly is simpler than adding separate state flags that would need synchronization.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64586", "url": "https://ubuntu.com/security/CVE-2026-64586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: drain bus_reset work on device removal brcmf_fw_crashed() and the debugfs \"reset\" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs \"reset\" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. 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-68208", "url": "https://ubuntu.com/security/CVE-2026-68208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: Fix the error code of devm_kzalloc() in vip_probe_slice() In vip_probe_slice(), the error check for devm_kzalloc() incorrectly uses PTR_ERR_OR_ZERO() which returns 0 for NULL pointer. Return -ENOMEM for devm_kzalloc() failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68224", "url": "https://ubuntu.com/security/CVE-2026-68224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mali-c55: Fix possible ERR_PTR in enable_streams The media_pad_remote_pad_unique() function returns either a valid pointer or an ERR_PTR() on failure (-ENOTUNIQ if multiple links are enabled, -ENOLINK if no connected pad is found). The return value was assigned directly to isp->remote_src and dereferenced in the next line without checking for errors, which could lead to an ERR_PTR dereference. Add proper error checking with IS_ERR() before dereferencing the pointer. Also set isp->remote_src to NULL on error to maintain consistency with other error paths in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68237", "url": "https://ubuntu.com/security/CVE-2026-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: fix indefinite fence wait during GPU reset pre_reset only force-completes fences of MAPPED queues. A queue in any other state (e.g. mid-eviction) keeps its last_fence pending; after a GPU reset that fence never signals, so the eviction/suspend worker and process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and wedge the machine: INFO: task kworker/6:28 blocked for more than 120 seconds. Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu] Call Trace: dma_fence_wait_timeout+0x7e/0x130 amdgpu_userq_evict+0x67/0x140 [amdgpu] amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu] process_scheduled_works+0xa6/0x420 Force-complete every queue's fence regardless of state. The unmap and mark-hung step stays gated on MAPPED, since unmapping a queue that is not mapped is invalid. (cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68240", "url": "https://ubuntu.com/security/CVE-2026-68240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: publish dpagemap early to avoid device mapping leak on error drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68242", "url": "https://ubuntu.com/security/CVE-2026-68242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix NULL deref on sched_engine alloc failure Avoid using intel_context_put() before intel_context_init() in execlists_create_virtual() as the kref_put() inside would lead to NULL deref on the IOCTL path when sched_engine allocation fails. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68254", "url": "https://ubuntu.com/security/CVE-2026-68254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: require valid min/max vfreq for VRR Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68436", "url": "https://ubuntu.com/security/CVE-2026-68436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use kvzalloc to allocate struct dc struct dc has grown large over time (most of it the two inlined dc_scratch_space copies) and now sits close to the page allocator's 4 MiB contiguous allocation limit. Its actual size is not fixed by the source alone, it also depends on the compiler and the .config, so it can easily cross 4 MiB, e.g. with a newer GCC or a config change. dc_create() allocates it with kzalloc(). Once struct dc exceeds 4 MiB the request is rounded up to order 11 (8 MiB), which is above MAX_PAGE_ORDER, so the page allocator warns and returns NULL. dc_create() then fails, DM init fails and amdgpu probe aborts with -EINVAL: WARNING: mm/page_alloc.c:5197 at __alloc_frozen_pages_noprof+0x2f9/0x380 dc_create+0x38/0x660 [amdgpu] amdgpu_dm_init+0x2d9/0x510 [amdgpu] dm_hw_init+0x1b/0x90 [amdgpu] amdgpu_device_init.cold+0x150d/0x1e13 [amdgpu] amdgpu_driver_load_kms+0x19/0x80 [amdgpu] amdgpu_pci_probe+0x1e2/0x4c0 [amdgpu] dc_create() then returns NULL and DM init fails, which aborts the whole GPU init and makes amdgpu probe fail with -EINVAL (\"hw_init of IP block failed -22\"), leaving the display unusable. The subsequent amdgpu_irq_put() warnings during teardown are just fallout of unwinding a half-initialized device. struct dc is a software-only bookkeeping structure that is never handed to hardware DMA and is only ever kept as an opaque pointer, so it does not require physically contiguous memory. Allocate it with kvzalloc() (and free it with kvfree()) so that the allocator can fall back to vmalloc() when a contiguous allocation of that size is not available, which also avoids the MAX_PAGE_ORDER warning entirely. v2: - Rebase to amd-staging-drm-next. (cherry picked from commit 991e0516a8072f2292681c6ae98a924ab0e32575)", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68447", "url": "https://ubuntu.com/security/CVE-2026-68447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size from hardware without bounding it to the allocated BO region. If the HW field is larger than the queue's control stack allocation, memcpy reads past the BO into adjacent GTT memory and can leak kernel data to userspace. Store the page-aligned control stack BO size in mqd_manager and clamp checkpoint copies and reported checkpoint sizes to min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound for multi-XCC v9.4.3 checkpoint layout. (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3)", "cve_priority": "high", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68264", "url": "https://ubuntu.com/security/CVE-2026-68264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: Reset current_op in xe_pt_update_ops_init() xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it. After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind. Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry. Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(). v2 (Matt): - Add details in commit message. - Add Fixes tag and Cc to stable@vger.kernel.org (cherry picked from commit 046045543e530605c441063535e7dca0075369a6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68265", "url": "https://ubuntu.com/security/CVE-2026-68265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO's tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference (cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68267", "url": "https://ubuntu.com/security/CVE-2026-68267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists Unconditionally whitelisting OA registers is a security violation. Set RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers don't get whitelisted by default after probe, gt reset, resume and engine reset. (cherry picked from commit 90511bdcfda97211c01f1d945d4ea616578d8fca)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68273", "url": "https://ubuntu.com/security/CVE-2026-68273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68274", "url": "https://ubuntu.com/security/CVE-2026-68274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix buffer overflow in steered register list allocation The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt->fuse_topo.g_dss_mask, ...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68283", "url": "https://ubuntu.com/security/CVE-2026-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free freeing trigger private data Commit 61d445af0a7c (\"tracing: Add bulk garbage collection of freeing event_trigger_data\") moved the kfree() of event_trigger_data to a kthread that runs tracepoint_synchronize_unregister() before freeing. That removed the synchronization the trigger .free callbacks used to get implicitly and inline from trigger_data_free(). event_hist_trigger_free(), event_hist_trigger_named_free() and event_enable_trigger_free() free their satellite data (hist_data, cmd_ops, enable_data) right after trigger_data_free() returns. With the synchronization now deferred to the kthread, a concurrent tracepoint handler can still reach that data through the list_del_rcu()'d trigger, causing a use-after-free. The histogram teardown must stay synchronous: remove_hist_vars() and unregister_field_var_hists() have to detach a synthetic event from the histogram before the trigger-removal write returns, otherwise a following command races in and the synthetic-event removal fails with -EBUSY, as the trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait with the correct barrier - tracepoint_synchronize_unregister(), matching the free kthread - before freeing. The enable trigger has no such synchronous requirement, and a blocking synchronize there would re-serialize the path that commit deliberately deferred. Give it an optional private_data_free() callback that the free kthread runs after its grace period, and free enable_data from there.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68286", "url": "https://ubuntu.com/security/CVE-2026-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68287", "url": "https://ubuntu.com/security/CVE-2026-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix size calculations for 64-bit attributes net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68288", "url": "https://ubuntu.com/security/CVE-2026-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68289", "url": "https://ubuntu.com/security/CVE-2026-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68291", "url": "https://ubuntu.com/security/CVE-2026-68291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix max_vport related crash on allocation error during init Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000 [ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000 [ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20 [ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000 [ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0 [ 320.417385] PKRU: 55555554 [ 320.417398] Call Trace: [ 320.417412] [ 320.417429] pci_device_remove+0x42/0xb0 [ 320.417459] device_release_driver_internal+0x1a9/0x210 [ 320.417492] driver_detach+0x4b/0x90 [ 320.417516] bus_remove_driver+0x70/0x100 [ 320.417539] pci_unregister_driver+0x2e/0xb0 [ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0 [ 320.417592] ? kmem_cache_free+0x31e/0x550 [ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190 [ 320.417644] ? do_syscall_64+0x38/0x6b0 [ 320.417665] do_syscall_64+0xc8/0x6b0 [ 320.417683] ? clear_bhb_loop+0x30/0x80 [ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 320.417727] RIP: 0033:0x7f963bb30beb", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68303", "url": "https://ubuntu.com/security/CVE-2026-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hvs/v3d: Fix null dereference in unbind The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68312", "url": "https://ubuntu.com/security/CVE-2026-68312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and cifs_close_deferred_file_under_dentry(), when a pending deferred close is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to add the file to the local processing list may fail under memory pressure. The loop breaks immediately, but the cancelled work is no longer pending (it would have called _cifsFileInfo_put()), and the cfile is never added to file_head for processing. The cifsFileInfo reference and the open server handle both leak. Fix by saving the cfile that failed allocation in a local variable, breaking as before, and calling _cifsFileInfo_put() on it after releasing the lock. Any files later in the iteration are unaffected since their deferred work is still pending and will fire normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68316", "url": "https://ubuntu.com/security/CVE-2026-68316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Fix element size accounting for cmd stream validation There are 2 issues with the element size handling in the command stream validation which result in too small of a size calculated when the element size is 16/32/64 bits. For NHWC format, the element size is simply missing from the calculation. The bitfield for the element size is different between IFM/IFM2 and OFM. IFM and IFM2 encode the precision in parameter bits 2:3, while OFM uses bits 1:2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68440", "url": "https://ubuntu.com/security/CVE-2026-68440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix heap overflow when reading module EEPROM txgbe_read_eeprom_hostif() always copies round_up(length, 4) bytes into the caller buffer, which ethtool allocates with exactly 'length' bytes. A non-4-aligned length therefore causes an out-of-bounds write. Copy only the remaining bytes on the final dword instead.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68323", "url": "https://ubuntu.com/security/CVE-2026-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: serialize udp bearer replicast list updates tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68441", "url": "https://ubuntu.com/security/CVE-2026-68441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected. This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d (\"bpf: add bpf_redirect() helper\"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available. commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs. Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a wrapper around tcf_classify() for use by qdisc classify functions and tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT, the wrapper converts it to TC_ACT_SHOT, dropping the packet rather than letting it continue silently. Dropping is preferred over letting the packet through because the user immediately sees packet loss. Silently passing the packet through would hide the problem and leave the user wondering why their redirect is not working. The clsact fast path, tc_run() continues to call tcf_classify() directly and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by sch_handle_egress/ingress() calling skb_do_redirect() as before.", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68337", "url": "https://ubuntu.com/security/CVE-2026-68337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject redirect helpers without a bpf_net_context The bpf_redirect*() helpers and skb_do_redirect() obtain the per-task bpf_redirect_info via bpf_net_ctx_get_ri(), which dereferences the current->bpf_net_context unconditionally. That context is established on the paths that run tc BPF such as sch_handle_{ingress,egress}(), *except* for the case where {cls,act}_bpf was attached to a proper qdisc. A program running from there reaches the NULL deref in two ways: * It calls bpf_redirect() directly, which dereferences the context at the top of the helper: tc qdisc add dev eth0 root handle 1: red limit 1MB min 10KB max 20KB \\ avpkt 1000 burst 100 qevent early_drop block 10 tc filter add block 10 pref 1 bpf obj redirect.o * It simply returns TC_ACT_REDIRECT without helper call: tcf_qevent_handle() then dispatches to skb_do_redirect(), which dereferences the context Rather than extending bpf_net_context management into the qdisc path, make the redirect helpers refuse to operate when no context exists, and have tcf_qevent_handle() drop a TC_ACT_REDIRECT verdict instead of calling skb_do_redirect(). Previous behaviour was a crash, so nothing regresses by not supporting it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68345", "url": "https://ubuntu.com/security/CVE-2026-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm_mpam: guard MBWU state before adding it to garbage __destroy_component_cfg() adds each RIS mbwu_state object to the MPAM garbage list when destroying component configuration. However, mbwu_state is allocated per RIS and only for RISes with MBWU monitors. A component can therefore have comp->cfg allocated while some RISes still have ris->mbwu_state set to NULL. Passing a NULL mbwu_state to add_to_garbage() dereferences the NULL pointer inside the macro. Skip RISes that do not have an mbwu_state object before adding them to the garbage list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68347", "url": "https://ubuntu.com/security/CVE-2026-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68375", "url": "https://ubuntu.com/security/CVE-2026-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle partially initialized auxiliary devices bnxt_aux_devices_init() calls auxiliary_device_init() before all fields used by bnxt_aux_dev_release() are initialized. After auxiliary_device_init() succeeds, later errors must unwind with auxiliary_device_uninit(), which invokes the release callback. The release callback assumes that aux_priv->id, aux_priv->edev, edev->net and edev->ulp_tbl are all populated. If allocation fails after auxiliary_device_init(), the release path can otherwise dereference or clear partially initialized state. Allocate and attach the bnxt_en_dev and ULP table before calling auxiliary_device_init(), so the release callback only sees a fully initialized auxiliary private object. If auxiliary_device_init() itself fails, free those allocations directly because device_initialize() has not run and the release callback will not be invoked. 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-68382", "url": "https://ubuntu.com/security/CVE-2026-68382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Hold device ref until queue teardown completes GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock. Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending. Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work. With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. Replace the fini wait with an assertion and remove the unused fini_wq. v2: - Rebase v3: - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt) - Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt) - Drop separate deferred drm_dev_put worker. - Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini(). v4: - Replace the guc_submit_sw_fini() wait with an assertion and remove the now-unused fini_wq. (sashiko) v5: - Move destroy work to a module-lifetime Xe workqueue instead of system_dfl_wq. (Matt) - Flush the module-lifetime destroy workqueue during PCI remove to preserve the old device-remove wait semantics. v6: - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid letting it outlive the xe_device/drm_device. (Sashiko) - Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work can be queued from the reclaim path. v7: - Drop the per-device xe->destroy_wq and use the module-level destroy WQ for SVM pagemap destroy as well. (Matt) - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*() helpers because the WQ is no longer exec-queue specific. (Matt) v8: - Rebase. v9: - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM destroy_wq because it can be queued from reclaim and embeds the dev_pagemap used by devres teardown. (Sashiko) - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM from it. - Update the module-WQ kdoc to document the GuC/SVM split. v10: - Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the workqueue allocation warning. v11: - Drop the SVM pagemap destroy comment as it was revision-specific. (Thomas) v12: - Rebase. (cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68383", "url": "https://ubuntu.com/security/CVE-2026-68383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Keep scheduler timeline name alive The scheduler keeps a pointer to the timeline name, but q->name is freed with the exec queue while scheduler fences can still reference it. Store the name in struct xe_guc_exec_queue so it shares the scheduler's RCU-deferred lifetime. (cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68390", "url": "https://ubuntu.com/security/CVE-2026-68390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups hci_conn_params_lookup requires hdev->lock be held, otherwise the list iteration or param access is not safe. Hold hdev->lock for params lookups in hci_sync.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-2026-68404", "url": "https://ubuntu.com/security/CVE-2026-68404", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: use wiphy work for socket owner autodisconnect nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68367", "url": "https://ubuntu.com/security/CVE-2026-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: synchronize delayed set_alt with teardown The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68095", "url": "https://ubuntu.com/security/CVE-2026-68095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse-uring: fix race between registration and connection abortion This fixes this race: - thread a: io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref yet - thread b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() is a no-op due to queue ref being 0 - thread a: grabs the queue_ref, queue_ref is now 1, rest of fuse_uring_do_register() logic executes - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs and calls \"wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);\" The abort/unmount thread will hang indefinitely in unkillable state as nothing will decrement queue_refs or wake stop_waitq, and the ring, queue, and ent are leaked. Fix this by checking fch->connected under fch->lock after the created ent has grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either release the queue ref and wake up stop_waitq (in case fuse_chan_wait_aborted() is already waiting) in fuse_uring_do_register() when we detect !fch->connected, or if the connection is aborted after the check, it is guaranteed that the async teardown worker will be running in the background cleaning up ents and decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-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-68173", "url": "https://ubuntu.com/security/CVE-2026-68173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: wait on ublk_dev_ready() instead of ub->completion ub->completion is only re-armed by a successful START_USER_RECOVERY. If the ublk server sends END_USER_RECOVERY without one - e.g. its START failed with -EBUSY and the error was ignored - the wait is satisfied by the stale completion of the previous recovery cycle, and the device is marked LIVE and the requeue list kicked while the FETCH stream is still running and ubq->canceling is still set. The kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it again via __ublk_abort_rq(), and after the last FETCH clears ->canceling nothing ever kicks the requeue list again: the request is stranded there while holding its tag. If it is the flush machinery's flush_rq, every subsequent fsync piles up in uninterruptible sleep and teardown hangs on tag draining. This matches a report of a lost PREFLUSH with ext4 on top of ublk after daemon crash recovery. ub->completion is an edge-triggered latch used as a proxy for the level condition \"every queue has fetched all I/O commands\", which can regress (F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop it and wait on the real condition instead: the new helper ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then re-checks it under ub->mutex, waiting again on regression, and returns with the mutex held and readiness guaranteed. Readiness becomes true in the same ub->mutex critical section that clears the last queue's ->canceling, so END_USER_RECOVERY marks the device LIVE and kicks the requeue list strictly after ->canceling clears. The wait stays interruptible, so a server whose daemon died can still be signalled out. For ublk_ctrl_start_dev() this replaces the fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting until the device is ready again.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68113", "url": "https://ubuntu.com/security/CVE-2026-68113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68118", "url": "https://ubuntu.com/security/CVE-2026-68118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: challenge ACK for non-exact RST in SYN-RECEIVED The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68120", "url": "https://ubuntu.com/security/CVE-2026-68120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtase: Workaround for TX hang caused by hardware packet parsing The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission.", "cve_priority": "medium", "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-68122", "url": "https://ubuntu.com/security/CVE-2026-68122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix peer refcount leak in TCP error paths When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&peer->tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object. The race window: CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error): ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2 schedule_work() <- queued schedule_work() <- NO-OP (work already pending) ovpn_tcp_peer_del_work runs: ovpn_peer_del() ovpn_peer_put() <- refcnt+1 <- peer never freed Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68128", "url": "https://ubuntu.com/security/CVE-2026-68128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: reject out-of-range ptype in ice_parser_profile_init set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from providing ptype >= 1024 through VIRTCHNL, resulting in a write past the end of the bitmap and a kernel page fault. Reproduced with a custom kernel module injecting a crafted VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1. crash_parser: ice_parser_profile_init @ ffffffffc0d61b60 crash_parser: setting ptype=0xffff (max valid=1023) crash_parser: calling ice_parser_profile_init -- expect OOB crash! BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace: ? __pfx_ice_parser_profile_init+0x10/0x10 [ice] crash_init+0x127/0xff0 [crash_parser] do_one_initcall+0x45/0x310 do_init_module+0x64/0x270 init_module_from_file+0xcc/0xf0 idempotent_init_module+0x17b/0x280 __x64_sys_finit_module+0x6e/0xe0 Bail out early with -EINVAL when ptype is out of range.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68132", "url": "https://ubuntu.com/security/CVE-2026-68132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: super: fix emergency thaw deadlock on frozen block devices do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68133", "url": "https://ubuntu.com/security/CVE-2026-68133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP Call Trace during PTP release If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will result in the following PTP release call trace during driver unload: kernel BUG at lib/list_debug.c:52! ice_ptp_release+0x332/0x3c0 [ice] ice_deinit_features.part.0+0x10e/0x120 [ice] ice_remove+0x100/0x220 [ice] This was observed when passing PF1 through to a VM. ice_ptp_init() fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT. Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and returning without error, preventing the invalid state transition to ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from ICE_PTP_RESETTING after a failed rebuild.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68134", "url": "https://ubuntu.com/security/CVE-2026-68134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: ptp_s390: Add missing facility check Only register the physical clock when facility 28 is installed and PTFF QAF returns that PTFF QPT is available.", "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-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-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-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-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-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-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-68150", "url": "https://ubuntu.com/security/CVE-2026-68150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/super: fix emergency thaw double-unlock of s_umount do_thaw_all() iterates over all superblocks via __iterate_supers() with SUPER_ITER_EXCL, which acquires s_umount exclusively before calling the callback and releases it afterwards. However, the callback do_thaw_all_callback() calls thaw_super_locked() which unconditionally releases s_umount on every code path. This results in a second unlock attempt in __iterate_supers() that corrupts the rwsem state, triggering a DEBUG_RWSEMS warning: [ 182.601148] sysrq: Emergency Thaw of all frozen filesystems [ 182.601865] ------------[ cut here ]------------ [ 182.602375] DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff99b1011e5870, owner = 0x0, curr 0xffff99b101b06c80, list not empty [ 182.603817] WARNING: kernel/locking/rwsem.c:1412 at up_write+0xa3/0x170, CPU#2: kworker/2:1/53 [ 182.604578] Modules linked in: [ 182.604864] CPU: 2 UID: 0 PID: 53 Comm: kworker/2:1 Not tainted 7.2.0-rc4-00001-gbd3bd93ea98a-dirty #4 PREEMPT(lazy) [ 182.605711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014 [ 182.606417] Workqueue: events do_thaw_all [ 182.606750] RIP: 0010:up_write+0xaf/0x170 [ 182.607076] Code: 19 3a 92 48 0f 44 c2 48 8b 55 08 48 8b 55 00 4c 8b 45 08 48 8b 55 00 48 8d 3d ad 91 e0 01 48 8b 4d 20 50 48 c7 c6 f0 8c 26 92 <67> 48 0f b9 3a e8 d7 93 4e 00 58 eb 81 48 83 7f 18 00 48 c7 c2 8d [ 182.608563] RSP: 0018:ffffb670001d7e08 EFLAGS: 00010246 [ 182.609007] RAX: ffffffff92349e8d RBX: 0000000000000000 RCX: ffff99b1011e5870 [ 182.609595] RDX: 0000000000000000 RSI: ffffffff92268cf0 RDI: ffffffff92914d10 [ 182.610283] RBP: ffff99b1011e5870 R08: 0000000000000000 R09: ffff99b101b06c80 [ 182.610847] R10: ffff99b10139a808 R11: fefefefefefefeff R12: 0000000000000000 [ 182.611414] R13: ffffffff90cf74d0 R14: 0000000000000000 R15: ffff99b1011e5800 [ 182.612009] FS: 0000000000000000(0000) GS:ffff99b1eaaee000(0000) knlGS:0000000000000000 [ 182.612670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 182.613146] CR2: 00000000005c631c CR3: 00000000013ee000 CR4: 00000000000006f0 [ 182.613722] Call Trace: [ 182.613946] [ 182.614130] __iterate_supers+0x128/0x150 [ 182.614463] do_thaw_all+0x1b/0x30 [ 182.614759] process_scheduled_works+0xbb/0x3f0 [ 182.615150] ? __pfx_worker_thread+0x10/0x10 [ 182.615499] worker_thread+0x129/0x270 [ 182.615816] ? __pfx_worker_thread+0x10/0x10 [ 182.616201] kthread+0xe2/0x120 [ 182.616469] ? __pfx_kthread+0x10/0x10 [ 182.616792] ret_from_fork+0x15b/0x240 [ 182.617115] ? __pfx_kthread+0x10/0x10 [ 182.617426] ret_from_fork_asm+0x1a/0x30 [ 182.617761] [ 182.617968] ---[ end trace 0000000000000000 ]--- [ 182.618412] Emergency Thaw complete Fix this by switching to SUPER_ITER_UNLOCKED and acquiring s_umount in the callback via super_lock_excl() before calling thaw_super_locked(). This matches the locking pattern expected by thaw_super_locked() and eliminates the double unlock. While at it, remove the dead 'return;' at the end of do_thaw_all_callback().", "cve_priority": "low", "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-68152", "url": "https://ubuntu.com/security/CVE-2026-68152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: fix use-after-free in AMT delayed works When an AMT device is removed, pending delayed works can still access the freed amt_dev structure, which may result in kernel crashes or memory corruption. amt_dev_stop() cancels req_wq and discovery_wq with cancel_delayed_work_sync(), but these works can be scheduled again from event_wq after the cancellation. This allows delayed works to access the freed amt_dev structure after the netdev has been released. The following is a simple race scenario: CPU0 CPU1 amt_dev_stop() cancel_delayed_work_sync() amt_event_work() mod_delayed_work(req_wq) free netdev req_wq accesses freed amt_dev Use disable_delayed_work_sync() in amt_dev_stop() to prevent req_wq and discovery_wq from being queued again and wait for running work items to complete. The delayed works are disabled after initialization in amt_newlink() and enabled only when the device is successfully opened. This keeps the delayed work lifecycle synchronized with the lifetime of the AMT device.", "cve_priority": "high", "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-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-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-68168", "url": "https://ubuntu.com/security/CVE-2026-68168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix afs_edit_dir_remove() to get, not find, block 0 Fix afs_edit_dir_remove() to use afs_dir_get_block() to get block 0 rather than afs_dir_find_block() as the latter caches the found block in the afs_dir_iter and may[*] switch out the page it's on if another afs_dir_find_block() is done. This parallels what afs_edit_dir_add() does. [*] There's more than one block per page.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68169", "url": "https://ubuntu.com/security/CVE-2026-68169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: userspace: fix use-after-free in get_local_id In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a \"not found\" sentinel.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68172", "url": "https://ubuntu.com/security/CVE-2026-68172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: make huge_ptep_get handled unaligned addresses huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma). The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned. On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map or into a hole, dereference a VA not mapped into the kernel pgtables and cause kernel panic. Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68174", "url": "https://ubuntu.com/security/CVE-2026-68174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix union collision of module and refcnt for dynamic events In 'struct trace_event_call', the 'module' pointer and the 'refcnt' atomic variable share the same memory space in a union. For dynamic events, the union member is 'refcnt', which acts as an active reference counter. When a dynamic event (such as kprobe, uprobe, fprobe, eprobe, or wprobe) has a non-zero reference count (e.g. due to active event triggers or perf attachments), its 'call->module' evaluates to a small non-zero integer instead of NULL. When filtering or setting events for a specific module (e.g., writing ':mod:' to 'set_event'), the code in '__ftrace_set_clr_event_nolock()' and 'update_event_fields()' reads 'call->module' directly without checking whether the event is dynamic. This causes the kernel to treat the small integer (refcnt) as a 'struct module' pointer, leading to a NULL/invalid pointer dereference (Oops) when dereferencing the module name. Fix this by ensuring that the 'TRACE_EVENT_FL_DYNAMIC' flag is checked before treating 'call->module' as a valid pointer in these code paths.", "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-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-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-68434", "url": "https://ubuntu.com/security/CVE-2026-68434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms Commit b1b4efea05a5 (\"serial: 8250_mid: Disable DMA for selected platforms\") replaced the dnv_board setup and exit callbacks with PTR_IF(false, ...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. Fix this by adding the missing NULL checks before calling the setup and exit callbacks.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17: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-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-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16: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-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-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-68198", "url": "https://ubuntu.com/security/CVE-2026-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix use-after-free in aggr_reset_state() The aggr_reset_state() function uses timer_delete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggr_module_destroy(). If the timer callback (aggr_timeout) is executing when aggr_reset_state() is called, the callback will continue to access aggr_conn fields like rx_tid[] and stat[] which may be freed immediately after by kfree(aggr_info->aggr_conn) in aggr_module_destroy(). Additionally, the timer callback can re-arm itself via mod_timer() while aggr_reset_state() is running, creating a more complex race condition. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "high", "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-68200", "url": "https://ubuntu.com/security/CVE-2026-68200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: don't re-enter an instance callback that is still running The userspace-driven timer (utimer) TRIGGER ioctl calls snd_timer_interrupt() directly with no serialization, so two threads triggering the same utimer can run snd_timer_interrupt() on one snd_timer concurrently. snd_timer_process_callbacks() drops timer->lock around each instance callback and marks the in-flight callback with the single SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that bit to drain an in-flight callback before freeing the instance. The bit cannot represent two concurrent callbacks: when a second interrupt re-queues an instance whose callback is still running, both run at once, the first to finish clears the bit, and the close-path drain then frees the instance (and its callback_data) while the other callback is still live - a use-after-free reachable by any user able to open /dev/snd/timer, both via a user timer instance and via a sequencer queue timer bound to the utimer. snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so a concurrent interrupt already observes it under the lock. Skip re-queuing an instance (and its slaves) to the ack/sack list while its callback is in flight; the accumulated pticks are delivered on the next tick, so no event is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68201", "url": "https://ubuntu.com/security/CVE-2026-68201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: drain a slave's callback before its master detaches it snd_timer_close_locked() drains the closing instance's own in-flight callback (IFLG_CALLBACK) before freeing it, but not its slaves'. When a master instance is closed, remove_slave_links() clears each slave's ->timer; the slave's own close then reads timer == NULL and takes the branch that skips the drain entirely (snd_timer_stop_slave() also no-ops on a NULL timer). So a slave whose callback is still running when the master is closed is freed underneath the live callback, leading to use-after-free. Drain the slaves too before remove_slave_links() severs them. snd_timer_stop() has already taken this instance off the active list, so no new slave callback can be queued. Take the slaves off the ack list so a pending one can't fire either, then wait for any that is already in flight.", "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-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-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-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-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-68211", "url": "https://ubuntu.com/security/CVE-2026-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32-dcmipp: 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. dcmipp_bytecap_start_streaming() returned -EINVAL when the source subdevice could not be resolved from the media graph, before pm_runtime_resume_and_get() and media_pipeline_start() had been called. The remaining error paths already converge on the err_buffer_done label, which calls dcmipp_bytecap_all_buffers_done(..., VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate err_pm_put / err_media_pipeline_stop 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": "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-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-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-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-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-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-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-68230", "url": "https://ubuntu.com/security/CVE-2026-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: amlogic-c3: Add validations for ae and awb config Avoid invalid memory access if the zones_num is bigger than zone_weight. This patch fixes the following smatch errors: drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max", "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-68232", "url": "https://ubuntu.com/security/CVE-2026-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path.", "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-68233", "url": "https://ubuntu.com/security/CVE-2026-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Shut down BO cache timer before teardown The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20: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-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-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-68238", "url": "https://ubuntu.com/security/CVE-2026-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Release VFCT ACPI table reference amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68239", "url": "https://ubuntu.com/security/CVE-2026-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Account for NULL and handle pages in ttm_pool_backup Pages in ttm_pool_backup can be NULL or backup handles (ttm_backup_page_ptr_is_handle()), neither of which can be passed to set_pages_array_wb() or freed. Add a dedicated WB pass before the dma/purge loop that walks allocations using the same i += num_pages stride, skipping NULL and handle entries, and calls set_pages_array_wb() once per contiguous run of real pages. Apply the same NULL/handle guard to the dma/purge loop. Fixes the following oops: Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI RIP: 0010:__cpa_process_fault+0xf8/0x770 RSP: 0018:ffffc90000a87718 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34 RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0 R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000 R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0 FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0 PKRU: 55555554 Call Trace: __change_page_attr_set_clr+0x989/0xe90 ? __purge_vmap_area_lazy+0x6c/0x3a0 ? _vm_unmap_aliases+0x250/0x2a0 set_pages_array_wb+0x7f/0x120 ttm_pool_backup+0x4c9/0x5b0 [ttm] ? dma_resv_wait_timeout+0x3b/0xf0 ttm_tt_backup+0x32/0x60 [ttm] ttm_bo_shrink+0x66/0x110 [ttm] xe_bo_shrink_purge+0x12b/0x1b0 [xe] xe_bo_shrink+0xbb/0x270 [xe] __xe_shrinker_walk+0xf7/0x160 [xe] xe_shrinker_walk+0x9d/0xc0 [xe] xe_shrinker_scan+0x11f/0x210 [xe] do_shrink_slab+0x13b/0x270 shrink_slab+0xf1/0x400 shrink_node+0x352/0x8a0 balance_pgdat+0x32c/0x700 kswapd+0x205/0x2f0 ? __pfx_autoremove_wake_function+0x10/0x10 ? __pfx_kswapd+0x10/0x10 kthread+0xd1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1b1/0x200 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68241", "url": "https://ubuntu.com/security/CVE-2026-68241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/mst: limit DP MST ESI service loop The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto. (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)", "cve_priority": "medium", "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-68245", "url": "https://ubuntu.com/security/CVE-2026-68245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only valid while the lock is still being held. Once xa_unlock_irqrestore is called and returned, the pointer is no longer under lock and is subject to modification. Since, the caller still dereferences vm->task_info in amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a use after unlock problem. Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid() through removing the amdgpu_vm_get_vm_from_pasid() function from amdgpu_vm.c and making the relevant code inline to hold the lock while it is still in use. (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)", "cve_priority": "high", "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-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-68252", "url": "https://ubuntu.com/security/CVE-2026-68252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68253", "url": "https://ubuntu.com/security/CVE-2026-68253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)", "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-68257", "url": "https://ubuntu.com/security/CVE-2026-68257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix 32-bit overflow in CWSR total size calculation total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68258", "url": "https://ubuntu.com/security/CVE-2026-68258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on CRIU restore queue type and mqd size We weren't checking whether the values provided in the private data in kfd CRIU restore were within bounds. For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it. For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations. (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)", "cve_priority": "low", "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-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-68266", "url": "https://ubuntu.com/security/CVE-2026-68266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68268", "url": "https://ubuntu.com/security/CVE-2026-68268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Return error on non-migratable faults requiring devmem Non-migratable faults that require devmem incorrectly jump to the 'out' label, which squashes the error code intended to be returned to the upper layers. Fix this by returning -EACCES instead. (cherry picked from commit c4508edb2c723de93717272488ea65b165637eac)", "cve_priority": "medium", "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-68270", "url": "https://ubuntu.com/security/CVE-2026-68270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Avoid possible truncation with calculating visible size Calculating the visible size of the system framebuffer can result in truncation of the result. The calculation uses 32-bit arithmetics, which can overflow if the values for height and stride are large. Fix the issue by multiplying with mul_u32_u32().", "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-68275", "url": "https://ubuntu.com/security/CVE-2026-68275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks up the bo_va for the buffer object in the caller's VM via amdgpu_vm_bo_find(), but uses the returned pointer without checking it. amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM, which is the normal case for a BO that has never been mapped. The result is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which expands to list_for_each_entry(mapping, &(bo_va)->valids, list) and dereferences bo_va, causing a NULL pointer dereference. This is reachable by any process able to issue the ioctl (render group) simply by requesting mapping info for an unmapped BO. Return -ENOENT when no bo_va is found, jumping to out_exec so the drm_exec context and GEM object reference are released. (cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68276", "url": "https://ubuntu.com/security/CVE-2026-68276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx: fix cleaner shader IB buffer overflow The cleaner shader sysfs path allocates a 16-dword (64 byte) IB but incorrectly fills (align_mask + 1) dwords. On GFX rings align_mask is 0xff, so the loop wrote 256 dwords into a 64-byte buffer, causing a kernel page fault. The IB only needs to be a minimal NOP shell to schedule the job; the cleaner shader itself is emitted on the ring via emit_cleaner_shader(). Fill 16 dwords to match the allocation. v2: Use ib_size_dw variable (Lijo) (cherry picked from commit bf21af331ebf72d0935fd70c73192414a422c03a)", "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-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-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-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-68282", "url": "https://ubuntu.com/security/CVE-2026-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: analogix_dp: Add missing error check for platform_get_resource() Add missing error check for platform_get_resource() return value to prevent NULL pointer dereference when memory resource is not available.", "cve_priority": "medium", "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-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-68292", "url": "https://ubuntu.com/security/CVE-2026-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues.", "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-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-68296", "url": "https://ubuntu.com/security/CVE-2026-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM Before commit 00d066a4d4ed (\"netdev_features: convert NETIF_F_LLTX to dev->lltx\"), NETIF_F_LLTX was set unconditionally in both __gre_tunnel_init() and ip6gre_tnl_init_features() alongside GRE_FEATURES: dev->features |= GRE_FEATURES | NETIF_F_LLTX; When that commit converted NETIF_F_LLTX to the dev->lltx flag, it placed 'dev->lltx = true' after the SEQ/CSUM early returns instead of before them. This causes GRE/GRETAP/ip6gre tunnels with SEQ or CSUM+encap to lose lockless TX, reintroducing _xmit_lock acquisition around their ndo_start_xmit. Since GRE xmit re-enters the stack via ip_tunnel_xmit(), holding _xmit_lock risks ABBA deadlock with the underlay device. CPU0 CPU1 ---- ---- lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); Fix by moving dev->lltx = true before the early returns in both functions, restoring the original unconditional behavior.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64575", "url": "https://ubuntu.com/security/CVE-2026-64575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: fix double sock release on batch realloc bpf_iter_tcp_batch() releases the current batch via bpf_iter_tcp_put_batch(), which drops the socket refs and rewrites each slot with the socket cookie, then grows the batch. cur_sk/end_sk are kept for bpf_iter_tcp_resume(), but on realloc failure the function returns ERR_PTR() before resume runs, leaving cur_sk < end_sk over slots that now hold cookies rather than sock pointers. bpf_iter_tcp_seq_stop() then calls bpf_iter_tcp_put_batch() again and dereferences a cookie as a struct sock. Empty the batch on the failure path so stop() does not release it again. The sockets were already freed by the first bpf_iter_tcp_put_batch(), so nothing leaks, and a later read() rescans the bucket from the start instead of skipping it. The sibling GFP_NOWAIT failure path still holds real socket references and is left for stop() to release. BUG: KASAN: null-ptr-deref in __sock_gen_cookie Read of size 8 at addr 0000000000000059 by task exploit ... __sock_gen_cookie (net/core/sock_diag.c:28) bpf_iter_tcp_put_batch (net/ipv4/tcp_ipv4.c:2918) bpf_iter_tcp_seq_stop (net/ipv4/tcp_ipv4.c:3270) bpf_seq_read (kernel/bpf/bpf_iter.c:205) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 entry_SYSCALL_64_after_hwframe Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68298", "url": "https://ubuntu.com/security/CVE-2026-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create() Commit 9e9787414882 (\"drm/xe/userptr: replace xe_hmm with gpusvm\") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a \"simple\" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). (cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4)", "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-68448", "url": "https://ubuntu.com/security/CVE-2026-68448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: check access to copy_file_range source with src mounter creds Commit 5dae222a5ff0c (\"vfs: allow copy_file_range to copy across devices\") allowed filesystems that implement the copy_file_range() f_op to decide if they want to access cross-sb copy from/to the same fs type. The same commit added checks to verify same sb copy for filesystems that implement ->copy_file_range() and do not support cross-sb copy at the time, namely, to ceph, fuse and nfs. The two remaining fs which implement ->copy_file_range(), cifs and overlayfs started to support cross-sb copy from this time. While overlayfs does support cross-sb copy when the two underlying files are on the same base fs, the copy operation on the two real files from two different overalyfs filesystems is performed with the mounter creds of the destination overlayfs and the read permission access hook for the source file was called with the wrong creds. This could cause either deny of access to copy which would otherwise be allowed (e.g. with splice) or allow read access to file which would otherwise be denied. Fix the latter case by explicitly verifying read access to source file with the source overlayfs mounter creds. The former case remains a quirk of cross-sb overlayfs copy, but userspace could fall back to regular copy so no harm done.", "cve_priority": "low", "cve_public_date": "2026-08-12 01:17: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-68307", "url": "https://ubuntu.com/security/CVE-2026-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix crash in reset link replay During reset recovery, mt7925_vif_connect_iter() replays firmware state for links tracked in mvif->valid_links. After MLO link changes or MCU timeout recovery, the driver bitmap can temporarily contain a link whose mac80211 bss_conf has already gone away. This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching the crash where x1, the second argument, is NULL: pc : mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] lr : mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] x2 : ffffff80a77f6018 x1 : 0000000000000000 x0 : ffffff8099402080 Call trace: mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common] Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA reset replay is unchanged because the helper still returns &vif->bss_conf for the legacy link.", "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-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-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-68311", "url": "https://ubuntu.com/security/CVE-2026-68311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: guard link STA in decap offload mt7925_sta_set_decap_offload() iterates over the vif valid_links mask when updating decap offload state for an MLO station. The station may not have a link STA for every valid link of the vif, so mt792x_sta_to_link() can return NULL for a link that belongs to the vif but not to the station. The function currently dereferences mlink before checking whether the link WCID is ready. If mlink is NULL, setting or clearing MT_WCID_FLAG_HDR_TRANS dereferences a NULL pointer. Skip links without a station link before touching mlink->wcid.", "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-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-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-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-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-68321", "url": "https://ubuntu.com/security/CVE-2026-68321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix FDIR filter leak on remove Perfect FDIR filters can be added while the interface is down and are kept on the software list for later restore. unregister_netdev() only calls ndo_stop when the device is up, so txgbe_fdir_filter_exit() in txgbe_close() is skipped in that case and the filters are leaked on driver remove. Free the filter list from txgbe_remove() as well.", "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-68330", "url": "https://ubuntu.com/security/CVE-2026-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix DMA direction for NPU mailbox buffer airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE, but some callers expect the NPU to write response data back into the same buffer: - airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into the buffer, then the caller reads it via memcpy() - airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back npu_stats_addr field in the response On non-cache-coherent architectures like EN7581 (Cortex-A53 without hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op — it does not invalidate the CPU cache. If the NPU-written cache line is still present in the CPU cache when the caller reads the buffer, the CPU observes stale data instead of the NPU response. This is a timing-sensitive bug: small mailbox buffers (~24 bytes) typically fit in a single cache line and may survive in the cache until the caller reads them, producing silent data corruption rather than a crash. The bug is more likely to trigger when the caller reads the response immediately after dma_unmap_single() without intervening cache-evicting operations. Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures dma_unmap_single() invalidates the CPU cache on non-coherent systems. The mailbox buffers are small so there is no performance concern.", "cve_priority": "low", "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-68332", "url": "https://ubuntu.com/security/CVE-2026-68332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix potential use-after-free in airoha_ppe_deinit() airoha_ppe_deinit() replaces the NPU pointer with NULL via rcu_replace_pointer() but does not wait for existing RCU readers to exit before calling ppe_deinit() and airoha_npu_put(). This can cause a use-after-free if a reader in an RCU read-side critical section still holds a reference to the NPU when it is freed. The init path (airoha_ppe_init) already calls synchronize_rcu() after rcu_assign_pointer(), but the deinit path introduced in commit 6abcf751bc08 (\"net: airoha: Fix schedule while atomic in airoha_ppe_deinit()\") omitted the matching barrier when switching from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer(). Add synchronize_rcu() before ppe_deinit() to ensure all existing RCU readers have completed before the NPU resources are released.", "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-68334", "url": "https://ubuntu.com/security/CVE-2026-68334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix io_thread race in rxrpc_wake_up_io_thread() rxrpc_wake_up_io_thread() checks local->io_thread before waking it, but then reloads the pointer for wake_up_process(). local->io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so the second load can see NULL even if the first load did not. Take a READ_ONCE() snapshot and use it for both the NULL check and the wake_up_process() call, as rxrpc_encap_rcv() already does.", "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-68341", "url": "https://ubuntu.com/security/CVE-2026-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix use after free in unlock_ovpn() unlock_ovpn() iterates over the release_list using llist_for_each_entry() and drops the peer reference inside the loop body via ovpn_peer_put(). If this drops the last reference, the peer is eventually freed. However, llist_for_each_entry() reads peer->release_entry.next in the loop advance expression, which runs after the body. By that time the peer may have already been freed, resulting in a use after free when advancing to the next list entry. Fix this by using llist_for_each_entry_safe(), which caches the next pointer before executing the loop body.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68342", "url": "https://ubuntu.com/security/CVE-2026-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: avoid putting unrelated P2P peer on socket release ovpn_peer_release_p2p() is called when an OVPN UDP socket is being destroyed. It checks the currently published P2P peer and releases it only if that peer still uses the socket being destroyed. A peer replacement can publish a new peer before the old UDP socket is destroyed. When the old socket destruction path runs afterwards, ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the new peer uses a different socket, the function takes the socket mismatch branch. That branch still calls ovpn_peer_put(peer). At this point, however, peer is the currently published replacement peer, not the peer associated with the socket being destroyed. Dropping its reference can free it while ovpn->peer still points to it, leading to later use-after-free accesses from the peer and socket cleanup paths. KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer object. In the reproducer, the object is allocated from ovpn_peer_new() via ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU callback processing. Observed access sites include ovpn_peer_remove(), ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn(). Fix this by returning from the socket mismatch branch without putting the peer.", "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-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-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-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-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-68356", "url": "https://ubuntu.com/security/CVE-2026-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: airoha: Prevent division by zero when clock frequency is zero clk_get_rate() can return 0 when the clock provider is not properly configured or the clock is unmanaged. The driver uses wdt_freq as a divisor directly in airoha_wdt_probe() to compute max_timeout and in airoha_wdt_get_timeleft() to compute the remaining time, which results in a division by zero. Add a check for wdt_freq == 0 in probe and return -EINVAL with dev_err_probe() to prevent the division by zero and provide a diagnostic message.", "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-68358", "url": "https://ubuntu.com/security/CVE-2026-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-kraken3) 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-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-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-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-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-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-68374", "url": "https://ubuntu.com/security/CVE-2026-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: sysfs: add lock to bos_descriptors_read() Add a lock to the function bos_descriptors_read(). This function accesses udev->bos, which could be simultaneously freed in usb_reset_and_verify_device(), a function that is commonly called in drivers all over the kernel.", "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-68378", "url": "https://ubuntu.com/security/CVE-2026-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions: - A pin is registered with two or more dpll devices (dpll_A, dpll_B) - The pin has ref_sync pairs with other pins - During unregistration of dpll_A's pins, a ref_sync partner pin is unregistered first, removing it from dpll_A->pin_refs - But since the partner pin is still registered with dpll_B, its dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT run and the partner stays in the pin's ref_sync_pins xarray - When the pin itself is then unregistered from dpll_A, the delete notification calls dpll_msg_add_pin_ref_sync() which finds the partner in ref_sync_pins, passes dpll_pin_available() (partner is still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A, partner) returns NULL because partner was already removed from dpll_A->pin_refs - The NULL priv pointer is passed to the driver's ref_sync_get callback, which dereferences it BUG: kernel NULL pointer dereference, address: 0000000000000034 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x] Call Trace: dpll_msg_add_pin_ref_sync+0xb8/0x200 dpll_cmd_pin_get_one+0x3b6/0x4b0 dpll_pin_event_send+0x72/0x140 __dpll_pin_unregister+0x5a/0x2b0 dpll_pin_unregister+0x49/0x70 Fix this by skipping ref_sync pins whose priv pointer cannot be resolved for the current dpll device.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68379", "url": "https://ubuntu.com/security/CVE-2026-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix TIME_WAIT socket reference leak on PSP policy failure Release the TIME_WAIT socket reference and jump to discard_it upon PSP policy failure in both IPv4 and IPv6 receive paths. This prevents a memory leak of tcp_tw_bucket structures.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68380", "url": "https://ubuntu.com/security/CVE-2026-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix use-after-free of mm_struct in job scheduler amdxdna_cmd_submit() stores current->mm in job->mm without holding any reference. aie2_sched_job_run() later access job->mm from the DRM scheduler worker thread. With only a raw pointer and no structural reference, the mm_struct can be freed before the scheduler runs the job. Fix this by calling mmgrab() to hold a structural mm_count reference for the lifetime of the job, paired with mmdrop() in every cleanup path.", "cve_priority": "high", "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-68384", "url": "https://ubuntu.com/security/CVE-2026-68384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits. - Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it. While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one. (cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68385", "url": "https://ubuntu.com/security/CVE-2026-68385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/checksum: Fix csum_partial() without vector facility Currently csum_partial() calls csum_copy() with copy=false and dst=NULL. On machines without the vector facility, csum_copy() falls back to cksm(dst, ...), causing the checksum to be calculated from address zero instead of the source buffer. The VX implementation already checksums data loaded from src. Make the fallback do the same by passing src to cksm().", "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-68387", "url": "https://ubuntu.com/security/CVE-2026-68387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: add locking for raw flags bitfield With commit 890e5198a6e5 (\"can: raw: use bitfields to store flags in struct raw_sock\") the formerly separate integer values have been integrated into a single bitfield. This led to a read-modify-write operation when changing a flag in raw_setsockopt() which now needs a locking to prevent concurrent access. Instead of adding a lock/unlock hell in each of the flag manipulations this patch introduces a wrapper for a new raw_setsockopt_locked() function analogue to the isotp_setsockopt[_locked]() approach in net/can/isotp.c [mkl: use Closes tag instead of Link]", "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-68393", "url": "https://ubuntu.com/security/CVE-2026-68393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: extend conn_hash lookup critical sections Using RCU-protected pointers outside the critical sections without refcount is incorrect and may result to UAF. Extend critical section to cover both hci_conn_hash lookup and use of the returned conn. Add surrounding rcu_read_lock() also when return value is not used, in preparation for RCU lockdep requirement to hci_lookup_le_connect(). This avoids concurrent deletion of the conn before we are done dereferencing it. Also, make sure to hold hdev->lock when accessing hdev->accept_list.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68394", "url": "https://ubuntu.com/security/CVE-2026-68394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update MGMT_OP_LOAD_CONN_PARAM queues conn_update_sync() when a single parameter update changes an existing LE central connection. The queued work currently stores a borrowed hci_conn_params entry from hdev->le_conn_params. A later LOAD_CONN_PARAM request can clear disabled parameters and free that entry before hci_cmd_sync_work() runs the queued callback. Do not keep the borrowed hci_conn_params pointer in queued work. Queue the hci_conn instead and hold a reference until the queued callback completes. When the work runs, revalidate that the connection is still present, look up the current hci_conn_params entry, and cancel the update if userspace removed that entry while the work was pending. Copy the interval values from the current params entry under hdev->lock, then drop the lock and keep using hci_le_conn_update_sync() to issue the update. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in conn_update_sync+0x2a/0xf0 [bluetooth] Read of size 1 at addr ffff88810c697126 by task kworker/u17:0/377 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 kasan_report+0xe0/0x110 conn_update_sync+0x2a/0xf0 [bluetooth] hci_cmd_sync_work+0x187/0x210 [bluetooth] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 Allocated by task 466: hci_conn_params_add+0xa6/0x240 [bluetooth] load_conn_param+0x4e1/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] Freed by task 474: kfree+0x313/0x590 hci_conn_params_clear_disabled+0x9b/0xc0 [bluetooth] load_conn_param+0x4bf/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth]", "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-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-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-68400", "url": "https://ubuntu.com/security/CVE-2026-68400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint memory access array and to comply with the FF-A spec instead of defaulting to `sizeof(struct ffa_mem_region)`. This requires moving `ffa_mem_region_additional_setup()` earlier in the setup flow. Also, add sanity checks to ensure the calculated descriptor offsets do not exceed `max_fragsize`.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68401", "url": "https://ubuntu.com/security/CVE-2026-68401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() Sashiko (locally) reports multiple out-of-bound issues in ffa_setup_and_transmit: 1) Writing ep_mem_access->reserved can write out of bounds for FFA versions < 1.2 as ffa_emad_size_get() returns 16 bytes in that case while reserved has an offset of 24. Instead of zeroing fields, memset the struct to zero first based on the FFA version. 2) Make sure there is enough size to write constituents. While at it, convert the only sizeof() in the driver that uses a type instead of variable.", "cve_priority": "high", "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-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-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-68409", "url": "https://ubuntu.com/security/CVE-2026-68409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: defer link RX stats percpu free to RCU sta_remove_link() frees a removed MLO link's RX stats percpu buffer right away, but defers only the link container to RCU: \tsta_info_free_link(&alloc->info); \tkfree_rcu(alloc, rcu_head); The RX fast path reads link_sta under rcu_read_lock and writes the percpu stats. A reader that resolved link_sta before the removal keeps the pointer. The container stays alive from the kfree_rcu, so the read still works. But the percpu block it points to is already freed. This needs uses_rss. That is when pcpu_rx_stats exists. The full STA teardown frees the deflink stats only after synchronize_net(). The link removal path had no such barrier. The race is hard to win in practice, but the free should still wait for RCU. Free the link together with its data from a single RCU callback, so the percpu block is reclaimed only after readers drain.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20: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-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-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-68412", "url": "https://ubuntu.com/security/CVE-2026-68412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan() If the test against IEEE80211_MAX_SSID_LEN fails, then 'creq' leaks. Use the existing error handling path to fix it.", "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-64566", "url": "https://ubuntu.com/security/CVE-2026-64566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags() When iptfs_skb_add_frags() copies frag references from the source frag walk into a new SKB, it increments the page reference count via __skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the destination SKB's skb_shinfo->flags. If the source SKB carries shared frags (e.g. from a page-pool backed receive path), the new inner SKB will appear to ESP as having privately owned frags. A subsequent esp_input() call for a nested transport-mode SA then takes the no-COW fast path and decrypts in place, writing over pages that are still referenced by the outer IPTFS SKB. This causes kernel-visible memory corruption and can trigger a panic. All other frag-transfer helpers in the kernel (skb_try_coalesce, skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this convention by setting the flag inside the loop immediately after __skb_frag_ref() and nr_frags++, so every exit path that attaches a frag unconditionally propagates SKBFL_SHARED_FRAG.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68415", "url": "https://ubuntu.com/security/CVE-2026-68415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear mode callbacks after failed mode setup xfrm_state_gc_task can run long after a failed IPTFS state setup. In the reproduced case, __xfrm_init_state() cached x->mode_cbs, IPTFS setup returned -ENOMEM before publishing mode_data, and the temporary module reference from xfrm_get_mode_cbs() was dropped immediately. The dead state then kept x->mode_cbs until deferred GC ran after xfrm_iptfs had been unloaded. Clear x->mode_cbs when mode init or clone fails before publishing mode_data. Those states never installed mode-specific state or the long-term IPTFS module pin, so deferred GC has nothing mode-specific to destroy and must not retain a callback table pointer past the temporary lookup reference. The buggy scenario involves two paths, with each column showing the order within that path: failed setup path: 1. cache x->mode_cbs 2. mode setup fails before mode_data 3. drop the temporary module ref 4. dead state keeps x->mode_cbs cached GC/unload path: 1. xfrm_state_put() queues GC work 2. xfrm_iptfs unloads later 3. xfrm_state_gc_task runs 4. GC dereferences stale x->mode_cbs This also covers the failed clone path where clone_state() returns before publishing mode_data. Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y failslab_stacktrace_filter matched xfrm_iptfs frames ack_error=-12 FAULT_INJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrm_state_gc_task RIP: xfrm_state_gc_task+0x142/0x650 Modules linked in: esp4_offload xfrm_user [last unloaded: xfrm_iptfs] Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68418", "url": "https://ubuntu.com/security/CVE-2026-68418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent user-triggered null deref on QP create Previously, the user QP creation path would only attempt to populate iwqp->iwpbl if the user-provided req.user_wqe_bufs field was non-zero. The problem is that iwqp->iwpbl is unconditionally dereferenced later on in irdma_setup_virt_qp. While there was a check for iwqp->iwpbl != NULL, this check would only occur if req.user_wqe_bufs was non-zero. The end result is that a user could send a zero user_wqe_bufs value and trigger a null ptr deref. Fix this by unconditionally calling irdma_get_pbl and bailing if it fails, similar to the CQ and SRQ paths.", "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-68420", "url": "https://ubuntu.com/security/CVE-2026-68420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: reject optional IPTFS templates in outbound policies syzbot reported a stack-out-of-bounds read in xfrm_state_find() which flows from xfrm_tmpl_resolve_one(). Commit 3d776e31c841 (\"xfrm: Reject optional tunnel/BEET mode templates in outbound policies\") disallowed optional tunnel and BEET in outbound policies to prevent this. Later when IPTFS added, it was not covered by that fix and can still trigger the out-of-bounds read; Extend the check to disallow optional IPTFS in outbound policies as well. IPTFS should be identical to tunnel mode. IN and FWD policies are not affected: xfrm_tmpl_resolve_one() is only reachable via the outbound path. Reproducer, before: ip link add dummy0 type dummy ip link set dummy0 up ip addr add 10.1.1.1/24 dev dummy0 ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 mode transport ping -W 1 -c 1 10.1.1.2 PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data. [ 64.168420] ================================================================== [ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844 [ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full) [ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 64.169977] Call Trace: [ 64.169977] [ 64.169977] dump_stack_lvl+0x47/0x70 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] print_report+0x152/0x4b0 [ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0 [ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20 [ 64.169977] ? __virt_addr_valid+0x21b/0x230 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] kasan_report+0xa8/0xd0 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm_dst_hash+0x24/0xc0 [ 64.169977] xfrm_state_find+0xa2d/0x2f90 [ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570 [ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10 [ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 64.169977] ? kernel_text_address+0x5b/0x80 [ 64.169977] ? __kernel_text_address+0xe/0x30 [ 64.169977] ? unwind_get_return_address+0x5e/0x90 [ 64.169977] ? arch_stack_walk+0x8c/0xe0 [ 64.169977] xfrm_tmpl_resolve+0x130/0x200 [ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10 [ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110 [ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10 [ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310 [ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80 [ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10 [ 64.169977] ? ip_route_output_key_hash+0xc6/0x110 [ 64.169977] ? kasan_save_track+0x10/0x30 [ 64.169977] xfrm_lookup_route+0x18/0xe0 [ 64.169977] ip4_datagram_release_cb+0x4c9/0x530 [ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10 [ 64.169977] ? do_raw_spin_lock+0x71/0xc0 [ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 64.169977] release_sock+0xb0/0x170 [ 64.169977] udp_connect+0x43/0x50 [ 64.169977] __sys_connect+0xa6/0x100 [ 64.169977] ? alloc_fd+0x2e9/0x300 [ 64.169977] ? __pfx___sys_connect+0x10/0x10 [ 64.169977] ? preempt_latency ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68421", "url": "https://ubuntu.com/security/CVE-2026-68421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx() put_prev_task_scx() warns when a runnable task drops to a lower sched_class without SCX_OPS_ENQ_LAST, on the assumption that balance_one() would have kept it running. Core scheduling breaks that: a forced-idle SMT sibling reschedules through the core_pick fast path in pick_next_task(), which skips pick_task_scx() and thus balance_one(), so a runnable task can drop to idle with ENQ_LAST unset. Gate the warning on sched_cpu_cookie_match(): a cookie mismatch means core scheduling forced the idle, while a match (or core scheduling off) still catches a genuine missing-ENQ_LAST drop.", "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-68426", "url": "https://ubuntu.com/security/CVE-2026-68426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix stale skb->prev after async crypto steals a GSO segment skb_gso_segment() leaves the segment list head with ->prev pointing at the last segment, an invariant validate_xmit_skb_list() relies on when it sets its tail pointer (tail = skb->prev). When validate_xmit_xfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validate_xmit_skb_list() later does tail->next = skb, writing through that stale pointer -- a use-after-free. Repoint skb->prev at the last retained segment before returning.", "cve_priority": "critical", "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-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-2023-20585", "url": "https://ubuntu.com/security/CVE-2023-20585", "cve_description": "Insufficient checks of the RMP on host buffer access in IOMMU may allow an attacker with privileges and a compromised hypervisor to trigger an out of bounds condition without RMP checks, resulting in a potential loss of confidential guest integrity.", "cve_priority": "low", "cve_public_date": "2026-04-16 19:16:00 UTC" }, { "cve": "CVE-2026-68364", "url": "https://ubuntu.com/security/CVE-2026-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix ISM dc_lock deadlock during suspend [Why] System hang observed during suspend/resume while video is playing. amdgpu_dm_ism_disable() is called under dc_lock and waits for ISM delayed work via disable_delayed_work_sync(). The work handlers themselves take dc_lock, producing an ABBA deadlock when a worker is in flight at suspend time. [How] Split the disable path into two phases with opposite locking contracts: 1. amdgpu_dm_ism_disable() -- quiesces workers, must NOT hold dc_lock. 2. amdgpu_dm_ism_force_full_power() (new) -- drives the ISM FSM back to FULL_POWER_RUNNING, must hold dc_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72064", "url": "https://ubuntu.com/security/CVE-2026-72064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Sync page pool RX frags for CPU MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack.", "cve_priority": "medium", "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-72098", "url": "https://ubuntu.com/security/CVE-2026-72098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: fix buffer overflow in FEC calculation There's a buffer overflow in dm-verity-fec: if (neras && *neras <= v->fec->roots) \tfio->erasures[(*neras)++] = i; This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72248", "url": "https://ubuntu.com/security/CVE-2026-72248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: support IPIP tunnel with direct xmit The combination of IPIP tunnel with direct xmit, eg. bridge device, breaks because no dst_entry is provided to check the skb headroom and to set the iph->frag_off field. This leads to invalid dst usage and can trigger a crash in the tunnel transmit path. Fix this by moving dst_cache and dst_cookie out of the runtime union so that they can be shared by neighbour, xfrm, and direct tunnel flows. For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve route state in these shared fields and release it through the common dst release path. Since dst_entry is now available to the three supported xmit modes and dst_release() already deals with NULL dst, remove the xmit type check in nft_flow_dst_release(). Moreover, skip the check if the dst entry is NULL in nf_flow_dst_check() which is now the case for the direct xmit case. Based on patch from Rein Wei .", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72249", "url": "https://ubuntu.com/security/CVE-2026-72249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: use dst in this direction when pushing IPIP header When pushing the IPIP header, the route of the other direction is used to calculate the headroom, use the route in this direction. Accessing the other tuple to set the IP source and destination is fine because this tuple does not provide such information to avoid storing redundant information. However, this tuple already provides the dst for this direction, this went unnoticed because this bug affects headroom and iph->frag_off only at this stage.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72287", "url": "https://ubuntu.com/security/CVE-2026-72287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the \"normal\" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a \"late\" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72329", "url": "https://ubuntu.com/security/CVE-2026-72329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/liquidio: drop cached VF pci_dev LUT The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST. Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72355", "url": "https://ubuntu.com/security/CVE-2026-72355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix barriering when walking subrequest list Fix the barriering used when walking the subrequest list in retry as there's a possibility of seeing a subreq that's just been added by the application thread.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72412", "url": "https://ubuntu.com/security/CVE-2026-72412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/mm: Fix handling of _PAGE_UNUSED pte bit The _PAGE_UNUSED softbit should not really be lying around. Its sole purpose is to signal to try_to_unmap_one() and try_to_migrate_one() that the page can be discarded instead of being moved / swapped. KVM has no way to know why a page is being unmapped, so it sets the bit on userspace ptes corresponding to unused guest pages every time they get unmapped. KVM has no reasonable way to clear the bit once the page is in use again. While set_ptes() checks and clears the bit, other paths that set new ptes did not. This led to used pages being thrown out as if they were unused, causing guest corruption. Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in set_pte(), i.e. whenever a present pte is getting set. The check in set_ptes() is then redundant and can be removed. Also fix gmap_helper_try_set_pte_unused() to only set the bit if the pte is present; the _PAGE_UNUSED bit is only defined for present ptes and thus should not be set for non-present ptes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72417", "url": "https://ubuntu.com/security/CVE-2026-72417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto() Add sanity check for iph->ihl field in nf_flow_ip4_tunnel_proto() before using it to compute the header size, avoiding out-of-bounds access with malformed IP headers. While at it, use iph->protocol instead of the hardcoded IPPROTO_IPIP constant when setting ctx->tun.proto and reference ctx->tun.hdr_size when updating ctx->offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72442", "url": "https://ubuntu.com/security/CVE-2026-72442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: fix and simplify IP6IP6 tunnel handling Fix nf_flow_ip6_tunnel_proto() to use pskb_may_pull() instead of skb_header_pointer() to ensure the outer IPv6 header is in the skb headroom, which is required for subsequent packet processing. Move ctx->offset update inside the IPPROTO_IPV6 conditional block since it should only be adjusted when an IP6IP6 tunnel is actually detected. Simplify the rx path by removing ipv6_skip_exthdr() and checking ip6h->nexthdr directly, as the flowtable fast path only handles simple IP6IP6 encapsulation without extension headers. Drop the tunnel encapsulation limit destination option support from the tx path to match, since the rx path no longer handles extension headers. Remove the encap_limit parameter from nf_flow_offload_ipv6_forward(), nf_flow_tunnel_ip6ip6_push() and nf_flow_tunnel_v6_push(), along with the ipv6_tel_txoption struct and related headroom/MTU adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72463", "url": "https://ubuntu.com/security/CVE-2026-72463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix dev use-after-free in xfrm async resumption xfrm async resumption hold skb->dev refcnt until after transport_finish. However, xfrm_rcv_cb may modify skb->dev to tunnel dev without taking device reference, such as vti_rcv_cb. The subsequent async resumption will decrement the tunnel device's reference count, which lead to uaf of tunnel dev and refcnt leak of orig dev as below: unregister_netdevice: waiting for vti1 to become free. Usage count = -2 Stash the original skb->dev to fix refcnt imbalance. The new skb->dev set by xfrm_rcv_cb can race with device teardown. Extend rcu protection over xfrm_rcv_cb and transport_finish to prevent races.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72477", "url": "https://ubuntu.com/security/CVE-2026-72477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: call _ntfs_bad_inode() when failing to rename It is safe to call _ntfs_bad_inode on live inodes since: commit 519b078998ce (\"fs/ntfs3: Exclude call make_bad_inode for live nodes.\") The WARN_ON was added when it wasn't safe by: commit d99208b91933 (\"fs/ntfs3: cancle set bad inode after removing name fails\") Replace the WARN_ON with a call to _ntfs_bad_inode() to prevent further operations on the inconsistent inode.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72493", "url": "https://ubuntu.com/security/CVE-2026-72493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: serialize netif_running() check in enqueue_to_backlog() Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup(). The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit). Commit e9e4dd3267d0 (\"net: do not process device backlog during unregistration\") introduced a lockless netif_running() check in enqueue_to_backlog() to prevent queuing packets to an unregistering device. However, this creates a TOCTOU race window. A lockless transmitter (like veth_xmit) can pass the check before dev_close() clears IFF_UP. If the transmitter is then delayed, flush_all_backlogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed. Fix this by moving the netif_running() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netif_running() after the flush/close completes (so it gets dropped).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72494", "url": "https://ubuntu.com/security/CVE-2026-72494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Replace waitqueue and flag with completion The driver previously used a waitqueue along with an explicit request_done flag, but without proper barriers around request_done. An earlier patch by Gui-Dong Han attempted to fix this by adding the missing memory barriers. Rather than adding the barriers, this patch replaces the waitqueue+flag with a completion, which is designed for this exact purpose.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72496", "url": "https://ubuntu.com/security/CVE-2026-72496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Proper rollback if the ioremap fails bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74269", "url": "https://ubuntu.com/security/CVE-2026-74269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt: fix head underflow on XDP head-grow The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free. The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with this commit applied causes the test to run successfully to completion. The other rx_skb_func implementations don't have this issue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74350", "url": "https://ubuntu.com/security/CVE-2026-74350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate fast symlink target during inode read ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment. A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer. Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated. This keeps malformed fast symlinks from reaching the read path. Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x19f/0x330 (?:?) kasan_report+0xe0/0x110 (?:?) kasan_check_range+0x105/0x1b0 (?:?) __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72495", "url": "https://ubuntu.com/security/CVE-2026-72495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid repeated requests to allocate WC pages Applications can request multiple WC pages for the same ucontext. As of now, only 1 WC page per ucontext is supported. Add a lock to avoid concurrent access and a check to fail repeated requests. Also, if the mmap entry insert fails for the WC, free the Doorbell page index mapped for the WC page.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72501", "url": "https://ubuntu.com/security/CVE-2026-72501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Initialize dpi variable to zero dpi is initialized only for BNXT_RE_ALLOC_WC_PAGE, but copied for all the cases. So initialize the dpi to 0.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72278", "url": "https://ubuntu.com/security/CVE-2026-72278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Re-translate VNCR before injecting abort KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor updates and MMU faults.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68083", "url": "https://ubuntu.com/security/CVE-2026-68083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix path resolution in ksmbd_vfs_kern_path_create The SMB2 open lookup is rooted at the share with LOOKUP_BENEATH, but the create/mkdir/hardlink sink is not: ksmbd_vfs_kern_path_create() builds an absolute path with convert_to_unix_name() and resolves it from AT_FDCWD via start_creating_path(), so a \"..\" component is walked from the real filesystem root and escapes the export. An authenticated client races a missing path component so the rooted open lookup returns -ENOENT (taking the create branch) while the same component is present (a directory) when the create walk runs; the create then resolves \"..\" out of the share. Root the create walk at the share like the lookup and rename paths already are: resolve the parent with vfs_path_parent_lookup(..., LOOKUP_BENEATH, &share_conf->vfs_path) and create the final component with start_creating_noperm(). convert_to_unix_name() then has no callers and is removed.", "cve_priority": "high", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-68457", "url": "https://ubuntu.com/security/CVE-2026-68457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use opener credentials for FSCTL mutations SET_SPARSE, SET_ZERO_DATA and SET_COMPRESSION operate on an open SMB handle but call VFS xattr, fallocate or fileattr helpers with the current ksmbd worker credentials. Those helpers can revalidate inode permissions, ownership and LSM policy independently of the SMB handle access mask. Run each operation with the credentials captured in the target file when the handle was opened. Keep credential handling local to these single-file FSCTLs rather than applying session credentials to the complete IOCTL handler, which also contains handle-less and multi-handle operations.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72041", "url": "https://ubuntu.com/security/CVE-2026-72041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: use sk_msg_free_partial to fix partial send sk_msg_free_partial() ensures consistency of the skmsg at every iteration, without having to manually handle uncharges and offsets. This simplifies the code, and fixes some bugs in skmsg accounting when we don't send the full contents.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72046", "url": "https://ubuntu.com/security/CVE-2026-72046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing.", "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-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21: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-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72137", "url": "https://ubuntu.com/security/CVE-2026-72137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: nat_keepalive: avoid double free on send error nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6 send helper reports an error. That cleanup is only correct before the skb is handed to the output path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the networking stack may already have consumed the skb before returning an error, so freeing it again is unsafe. Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4() and nat_keepalive_send_ipv6(), where the caller still owns the skb, and keep nat_keepalive_send() responsible only for family dispatch and the unsupported-family cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72139", "url": "https://ubuntu.com/security/CVE-2026-72139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: defer md5sig_info kfree past RCU grace period in tcp_connect The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: \tif (needs_md5) { \t\ttcp_ao_destroy_sock(sk, false); \t} else if (needs_ao) { \t\ttcp_clear_md5_list(sk); \t\tkfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); \t} Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with tcp-diag]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72191", "url": "https://ubuntu.com/security/CVE-2026-72191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: validate split-point offset in indx_insert_into_buffer indx_insert_into_buffer() computes used = used1 - to_copy - sp_size; memmove(de_t, Add2Ptr(sp, sp_size), used - le32_to_cpu(hdr1->de_off)); where sp and sp_size come from hdr_find_split(). hdr_find_split() walks entries by le16_to_cpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFS_DE). index_hdr_check(), the on-load gatekeeper, only validates header-level fields (used, total, de_off) and does not walk per-entry sizes. A crafted NTFS image whose leaf INDEX_HDR reports used == total but contains one interior NTFS_DE with size = 0xFFF0 therefore passes validation, descends to indx_insert_into_buffer() through the ntfs_create() -> indx_insert_entry() path, and makes hdr_find_split() return an sp whose sp_size (0xFFF0) greatly exceeds the remaining bytes in the buffer. The u32 subtraction underflows and the memmove count becomes a near-4-GiB value, producing an out-of-bounds kernel write that corrupts adjacent allocations and panics the kernel. Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a single 'touch' inside the mounted directory; crash site resolves to fs/ntfs3/index.c at the memmove. Trigger requires only local mount of an attacker-supplied filesystem image (USB, loopback, or removable media auto-mount). Reject the split whenever the chosen sp plus its declared size already extends past hdr1->used. This is the minimal fix; it preserves the existing hdr_find_split() contract and relies on the same out: cleanup path as the pre-existing error returns. A prior OOB read in the very same indx_insert_into_buffer() memmove was fixed in commit b8c44949044e (\"fs/ntfs3: Fix OOB read in indx_insert_into_buffer\") by tightening hdr_find_e(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdr_find_split(), not hdr_find_e(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72217", "url": "https://ubuntu.com/security/CVE-2026-72217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing xdr_buf_to_bvec() writes a bio_vec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it. rq_bvec, the array passed by nfsd_vfs_write(), is allocated to exactly rq_maxpages entries with no slack. The OOB store can land in adjacent slab memory; the bv_len and bv_offset fields written there are derived from client-supplied RPC payload sizes. Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72220", "url": "https://ubuntu.com/security/CVE-2026-72220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp->rq_procinfo->pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72221", "url": "https://ubuntu.com/security/CVE-2026-72221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: wait for in-flight TLS handshake callback when cancel loses race When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed. The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result. If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue. If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed. Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed to fire because handshake_complete() invokes svc_tcp_handshake_done() unconditionally once it has set HANDSHAKE_F_REQ_COMPLETED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72222", "url": "https://ubuntu.com/security/CVE-2026-72222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: pin svc_xprt across the asynchronous TLS handshake callback svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of(). Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done. The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry. Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all(). [cel: rewrote commit message to describe the actual change]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72277", "url": "https://ubuntu.com/security/CVE-2026-72277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the simpler thing for now and just reject everything that isn't memory.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72279", "url": "https://ubuntu.com/security/CVE-2026-72279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR KVM currently maps the L1 VNCR into the host stage-1 by relying entirely on the permissions of the guest stage-1. At the same time, it is entirely possible that the backing PFN is read-only (e.g. RO memslot), meaning that the L1 VNCR should use at most a read-only mapping. Cache the writability of the PFN in the VNCR TLB and use it to constrain the resulting fixmap permissions. Promote VNCR permission faults to an SEA in the case where the guest attempts to write to a read-only endpoint. Conveniently, this also plugs a page leak found by Sashiko [*] resulting from the early return for a read-only PFN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72288", "url": "https://ubuntu.com/security/CVE-2026-72288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling Hyunwoo Kim reports some really bad races should the following situation occur: - LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C If the last two race nicely enough, vgic_prune_ap_list() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows. The fix is two-fold: - Before dropping the irq and ap_list locks, take a reference on the irq - Do not try to handle migration of the pending bit: there is no expectation that this state is retained, as per the architecture With that, we're sure that the interrupt is still around, and we safely remove it from the AP list as it has no target at this stage (unless another interrupt fires, but that's another story).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "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-72317", "url": "https://ubuntu.com/security/CVE-2026-72317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: pin upper rpc_clnt across the TLS connect_worker The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt. The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported. Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one. The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72318", "url": "https://ubuntu.com/security/CVE-2026-72318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate DFS referral string offsets parse_dfs_referrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server. Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative max_len is then passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds. Validate each string offset before deriving the string pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72320", "url": "https://ubuntu.com/security/CVE-2026-72320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_lookup: fix catchall element handling with inverted lookups nft_lookup_eval() decides whether a lookup matched (`found`) from the direct set lookup and priv->invert before falling back to the catchall element used by interval sets (e.g. nft_set_rbtree) for the open-ended default range. Since `found` is never recomputed after `ext` is replaced by the catchall lookup, inverted lookups (NFT_LOOKUP_F_INV, \"!= @set\") can wrongly match or wrongly skip the catchall element, producing the wrong verdict. Fold the catchall lookup into `ext` before computing `found`, matching the order already used by nft_objref_map_eval().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72366", "url": "https://ubuntu.com/security/CVE-2026-72366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_create_write_req() to handle async cache object creation netfs_create_write_req() will skip caching if the fscache cookie is disabled, but this is a problem because async cache object creation might not have got far enough yet that has been enabled - thereby causing the call to fscache_begin_write_operation() to be skipped. Fix this by removing the checks on the cookie and delegating this to fscache_begin_write_operation().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72381", "url": "https://ubuntu.com/security/CVE-2026-72381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of fp->owner.name in durable handle owner check Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d (\"ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd\") made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized. BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8 Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72393", "url": "https://ubuntu.com/security/CVE-2026-72393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: don't cache shinfo across skb realloc fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb including the shared info. We can't use the pointer calculated before the call. BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0 Read of size 4 at addr ff110000262edd98 by task swapper/5/0 Call Trace: fbnic_tx_lso.isra.0+0x668/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 Allocated by task 8653: __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xcc/0x6c0 sock_alloc_send_pskb+0x327/0x3f0 __ip_append_data+0x188b/0x47a0 ip_make_skb+0x24a/0x300 udp_sendmsg+0x14d2/0x21e0 Freed by task 0: kfree+0x123/0x5a0 pskb_expand_head+0x36c/0xfa0 fbnic_tx_lso.isra.0+0x500/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 sch_direct_xmit+0x25b/0x1100 The buggy address belongs to the object at ff110000262edc40 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 344 bytes inside of freed 640-byte region [ff110000262edc40, ff110000262ede", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72398", "url": "https://ubuntu.com/security/CVE-2026-72398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: add INIT verification after cookie unpacking In SCTP handshake, the INIT chunk is initially processed by the server and embedded into the cookie carried in INIT-ACK. The client then returns this cookie via COOKIE-ECHO, where the server unpacks it and reconstructs the original INIT chunk. When cookie authentication is enabled, the cookie contents are protected against tampering, so reusing the unpacked INIT without re-verification is safe. However, when cookie authentication is disabled, the reconstructed INIT can no longer be trusted. In this case, the INIT must be explicitly validated after unpacking to avoid processing potentially tampered data. Add sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO processing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook()) when cookie_auth_enable is disabled. On failure, the new association is freed and the packet is discarded. Also tighten cookie validation in sctp_unpack_cookie() by verifying the embedded chunk type is SCTP_CID_INIT before treating it as an INIT chunk. Finally, update sctp_verify_init() to validate parameter bounds using the actual embedded INIT length instead of chunk->chunk_end, since the INIT stored in COOKIE-ECHO may not span the entire chunk buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72399", "url": "https://ubuntu.com/security/CVE-2026-72399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: check the number of BDs needed for xdp_frame The size of xdp_redirect_arr array is ENETC_MAX_SKB_FRAGS. However, the number of fragments contained in xdp_frame may be greater than or equal to ENETC_MAX_SKB_FRAGS, which will cause the access to xdp_redirect_arr to be out of bounds.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72429", "url": "https://ubuntu.com/security/CVE-2026-72429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix type confusion of dst_entry IOAM uses a dummy dst_entry(null_dst) to mark that the destination should not be changed after the transformation. This dst is stored in the IOAM lwt state and may be passed to dst_cache_set_ip6(). However, the IPv6 dst cache path eventually calls rt6_get_cookie(), which treats the dst_entry as part of a struct rt6_info. Since the null_dst was embedded directly as a struct dst_entry in struct ioam6_lwt, this resulted in an invalid cast and rt6_get_cookie() reading fields from the wrong object. In practice, the wrong cookie is not used while dst->obsolete is zero, but rt6_get_cookie() may also access per-cpu value when rt->sernum is zero. In this case, rt->sernum aliases ioam6_lwt::cache::reset_ts, which can become zero, making this a potential invalid pointer access. Fix this by embedding a full struct rt6_info for the dummy IPv6 route and passing its dst member to the dst APIs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72436", "url": "https://ubuntu.com/security/CVE-2026-72436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash types Sashiko pointed out that there are a few lockless RCU readers using test_bit() which is a relaxed atomic operation and provides no memory barrier guarantees. Use test_bit_acquire() instead where the operation may run parallel with add/del/gc, i.e. is not one from the next cases - protected by region lock - in a set destroy phase - in a new/temporary set creation phase", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72451", "url": "https://ubuntu.com/security/CVE-2026-72451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix xfrm state cache insertion race The xfrm input state cache insertion code checks the validity of the state before acquiring the global xfrm_state_lock. Thus it's possible for someone else to kill the state after it passed the validity check, and then the insertion will add the dead state to the cache. Fix this by moving the validity check inside the lock. This entire function is called on the input path, where BH must be off (e.g., the caller of this function xfrm_input acquires its spinlocks without disabling BH). So there is no need to disable BH here or take the RCU read lock. Remove both and replace them with an assertion that trips if BH is accidentally enabled on some future calling path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72472", "url": "https://ubuntu.com/security/CVE-2026-72472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: use nfsi->rwsem to protect traversal of the file lock list Lingfeng identified a bug and suggested two solutions, but both appear to have issues. Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case. Furthermore, after commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk. Regarding the bug fixed by commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), it has been resolved after commit 0460253913e5 (\"NFSv4: nfs4_do_open() is incorrectly triggering state recovery\") because all slots are drained before calling nfs4_do_reclaim, which prevents concurrent stateid changes along this path. Also, nfs_delegation_claim_locks does not cause this concurrency either since when _nfs4_proc_setlk is called with NFS_DELEGATED_STATE, no RPC is sent, so nfs4_lock_done is not called. Therefore, nfs4_lock_delegation_recall from nfs_delegation_claim_locks is the first time the stateid is set.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72473", "url": "https://ubuntu.com/security/CVE-2026-72473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decouple req recycling from RPC completion rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer. Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off. The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry. Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied. Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected. Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released. The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74310", "url": "https://ubuntu.com/security/CVE-2026-74310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/net: complete zerocopy ubufs only once vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74345", "url": "https://ubuntu.com/security/CVE-2026-74345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix endpoint/socket association handling Disassociating a socket from an endpoint via siw_socket_disassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within. This fixes a: BUG: KASAN: slab-use-after-free in siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1053 drivers/infiniband/sw/siw/siw_cm.c:1075) which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74361", "url": "https://ubuntu.com/security/CVE-2026-74361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: fix FDP fdpcidx bounds check The fdpcidx bounds check sets n = NUMFDPC + 1 but used > instead of >=, incorrectly accepting fdp_idx when it equals n (i.e. NUMFDPC + 1).", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74401", "url": "https://ubuntu.com/security/CVE-2026-74401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix add msg handle in send_queue ordered In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as \"before(mh->seq, seq)\" will stop to check for older sequence numbers that are ordered in the tail of \"node->send_queue\". The side effects of not having it correct ordered regarding \"before(mh->seq, seq)\" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74406", "url": "https://ubuntu.com/security/CVE-2026-74406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74428", "url": "https://ubuntu.com/security/CVE-2026-74428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix double unlock in rxrpc_recvmsg() Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74433", "url": "https://ubuntu.com/security/CVE-2026-74433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix UAF in rxgk_issue_challenge() Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74434", "url": "https://ubuntu.com/security/CVE-2026-74434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Don't move a peeked OOB message onto the pending queue rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so only unlink it from recvmsg_oobq and then move it onto pending_oobq or free it when the message is actually consumed.", "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-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-74439", "url": "https://ubuntu.com/security/CVE-2026-74439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clear Present bit before tearing down scalable-mode context entry device_pasid_table_teardown() zeroes the 128-bit scalable-mode context entry with context_clear_entry() while the Present bit is still set. This creates a window where the hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behavior or spurious faults. The context-cache invalidation is issued only after the entry has been zeroed, and intel_pasid_free_table() then frees the PASID directory pages, so the IOMMU can keep walking a stale Present=1 entry that points at freed memory. While x86 provides strong write ordering, the compiler may reorder the two 64-bit writes to the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Commit c1e4f1dccbe9d (\"iommu/vt-d: Clear Present bit before tearing down context entry\") fixed this exact pattern in domain_context_clear_one() and the copied-context path, but device_pasid_table_teardown() was not converted. Align it with the \"Guidance to Software for Invalidations\" in the VT-d spec, Section 6.5.3.3, using the same ownership handshake as the sibling fix: clear only the Present bit, flush it to the IOMMU, perform the context-cache invalidation, and only then zero the rest of the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" } ], "log": [ "", " * noble/linux-riscv-7.0: 7.0.0-38.38.1~24.04.1 -proposed tracker (LP: #2165483)", "", " [ Ubuntu-riscv: 7.0.0-38.38.1 ]", "", " * resolute/linux-riscv: 7.0.0-38.38.1 -proposed tracker (LP: #2165484)", " * resolute: llvm-21-dev build-depends breaks cross-builds (LP: #2165407)", " - [Packaging] Fix cross-builds", " * Zfhmin/Zvfhmin not reported when Zfh/Zvfh are present (LP: #2166547)", " - riscv: report Zfhmin/Zvfhmin when Zfh/Zvfh are present", " [ Ubuntu: 7.0.0-38.38 ]", " * resolute/linux: 7.0.0-38.38 -proposed tracker (LP: #2166443)", " * linux: dtbs_install fails on Resolute builders due to uutils install(1)", " EEXIST race under parallel make (LP: #2166356)", " - SAUCE: [Packaging] Serialise dtbs_install to work around uutils", " install(1) race", " * #510/p sleepable raw tracepoint reject from test_verifier in ubuntu_bpf", " failed with resolute (7.0.0-33.33) generic amd64 (LP: #2165872)", " - SAUCE: Revert \"bpf: Verifier support for sleepable tracepoint programs\"", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189)", " - 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", " - seqlock: Allow UBSAN_ALIGNMENT to fail optimizing", " - KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN", " - crypto: tegra - Don't touch bo refcount in host1x bo pin/unpin", " - xprtrdma: Clear receive-side ownership pointers on release", " - Input: ims-pcu - fix logic error in packet reset", " - fuse: fix writeback array overflow when max_pages is one", " - arm64: tegra: Remove fallback compatible for GPCDMA", " - arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234", " - xfrm: propagate -EINPROGRESS from validate_xmit_xfrm()", " - mtd: mtdswap: remove debugfs stats file on teardown", " - mtd: nand: mtk-ecc: stop on ECC idle timeouts", " - btrfs: fallback to transaction csum tree on a commit root csum miss", " - RDMA/cma: Fix hardware address comparison length in netevent callback", " - RDMA/irdma: Remove redundant legacy_mode checks", " - RDMA/erdma: initialize ret for empty receive WR lists", " - RDMA/mana_ib: initialize err for empty send 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: cfg80211: derive S1G beacon TSF from S1G fields", " - wifi: nl80211: validate nested MBSSID IE blobs", " - wifi: nl80211: constrain MBSSID TX link ID range", " - wifi: cfg80211: validate PMSR measurement type data", " - wifi: cfg80211: reject unsupported PMSR FTM location requests", " - wifi: mac80211: avoid non-S1G AID fallback for S1G assoc", " - ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on", " start/stop", " - ASoC: amd: ps: disable MSI on resume in ACP PCI driver", " - ASoC: amd: ps: fix wrong ACP version string in pci_request_regions()", " - ASoC: amd: ps: replace bitwise OR with logical OR in IRQ return check", " - 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", " - cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq", " - udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()", " - ata: sata_dwc_460ex: use platform_get_irq()", " - ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending", " interrupts", " - accel/ivpu: Fix wrong register read in LNL failure diagnostics", " - ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC", " - drm/i915/gt: use correct selftest config symbol", " - powerpc/85xx: Add fsl,ifc to common device ids", " - powerpc/time: Prepare to stop elapsing in dynticks-idle", " - powerpc/vtime: Initialize starttime at boot for native accounting", " - drm/panthor: Check debugfs GEM lock initialization", " - riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()", " - can: j1939: fix lockless local-destination check", " - drm/xe/wopcm: fix WOPCM size for LNL+", " - drm/i915/wm: clear the plane ddb_y entries on plane disable", " - 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: gadget: fsl-udc: fix dev_printk() device", " - 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", " - SAUCE: Revert \"usb: typec: ucsi: Detect and skip duplicate altmodes from", " buggy firmware\"", " - usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware", " - wifi: mwifiex: fix freeze for 60 seconds caused by request_firmware", " - RISC-V: KVM: Serialize virtual interrupt pending state updates", " - Revert \"drm/amd/display: Add missing kdoc for ALLM parameters\"", " - usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits", " - selftests/bpf: Adjust verifier_map_ptr for the map's excl field", " - selftests/bpf: Keep verifier_map_ptr exercising ops pointer access", " - 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", " - btrfs: fix u32 to s64 type conversion in dirty_metadata_bytes accounting", " - ASoC: sun4i-codec: Set quirks.playback_only for H616 codec", " - 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: fix pointer arithmetic in iwl_add_mcc_to_tas_block_list", " - wifi: iwlwifi: validate payload length in iwl_pnvm_complete_fn", " - wifi: iwlwifi: mvm: fix read in wake packet notification handler", " - usb: atm: ueagle-atm: reject descriptors that confuse probe and", " disconnect", " - drivers/virt: pkvm: Fix end calculation in mmio_guard_ioremap_hook()", " - 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", " - selftests/net: ovpn: fix getaddrinfo memory leak in ovpn_parse_remote()", " - ovpn: use monotonic clock for peer keepalive timeouts", " - regulator: mt6358: use regmap helper to read fixed LDO calibration", " - net: phy: marvell: fix return code", " - netlink: specs: rt-link: convert bridge port flag attributes to u8", " - gtp: parse extension headers before reading inner protocol", " - vhost-net: fix TX stall when vhost owns virtio-net header", " - wifi: mac80211: recalculate TIM when a station enters power save", " - pds_core: reject component parameter in legacy firmware update", " - arm64: Correct value returned by ESR_ELx_FSC_ADDRSZ_nL()", " - amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN", " - soreuseport: Clear sk_reuseport_cb before failure in sk_clone().", " - net: Call net_enable_timestamp() before failure in sk_clone().", " - 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", " - selftests: af_unix: add USER_NS config", " - selftests: openvswitch: add config file", " - selftests: ovpn: add IPV6 and VETH configs", " - selftests: ovpn: increase timeout", " - selftests: drv-net: increase timeout", " - ppp: don't store tx skb in the fastpath", " - ppp: annotate concurrent dev->stats accesses", " - ovl: fix trusted xattr escape prefix matching", " - drm/panel: s6e3ha8: fix unmet dependency on DRM_DISPLAY_HELPER", " - 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", " - drm/xe/i2c: Allow per domain unique id", " - iomap: correct the range of a partial dirty clear", " - drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem", " - net: stmmac: xgmac: fix l4 filter port overwrite on register update", " - 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: annotate data races in ppp_generic", " - hinic: remove unused ethtool RSS user configuration buffers", " - raw: annotate lockless match fields in raw_v4_match()", " - 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", " - octeontx2-pf: tc: fix egress ratelimiting", " - net: ipv6: fix dif and sdif mismatch in raw6_icmp_error", " - ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV", " - ice: fix LAG recipe to profile association", " - ipv6: Change allocation flags to match rcu_read_lock section", " requirements", " - ptp: netc: explicitly clear TMR_OFF during initialization", " - mctp: check register_netdevice_notifier() error in mctp_device_init()", " - net: airoha: fix ETS channel derivation in airoha_tc_setup_qdisc_ets()", " - drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay", " - drm: renesas: rzg2l_mipi_dsi: Move rzg2l_mipi_dsi_set_display_timing()", " - drm/tidss: Fix missing drm_bridge_add() call", " - 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/sysfb: Do not page-align visible size of the framebuffer", " - drm/sysfb: Avoid truncating maximum stride", " - drm/amdgpu/gfx9: Fix Ring and IB test fail after mode2", " - drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT", " - drm/sysfb: Return errno code from drm_sysfb_get_visible_size()", " - drm/displayid: fix Tiled Display Topology ID size", " - drm/nouveau/acr: fix missing nvkm_done() in error path of", " nvkm_acr_oneinit()", " - drm/radeon: fix r100_copy_blit for large BOs", " - drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked binds", " - drm/amdkfd: Use kvcalloc to allocate arrays", " - drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips", " - drm/i915/hdcp: require monotonically increasing seq_num_v", " - drm/amd/amdgpu: disable ASPM on VI if pcie dpm is disabled", " - drm/amd/pm: fix smu14 power limit range calculation", " - drm/gfx10: Program DB_RING_CONTROL", " - drm/virtio: Don't detach GEM from a non-created context", " - drm/panthor: return error on truncated firmware", " - drm/amdgpu: Fix VFCT bus number matching with soft filter", " - drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)", " - drm/amd/display: consolidate DCN vblank/flip handling onto", " vupdate_no_lock", " - drm/amd/display: Force PWM backlight on Lenovo Legion 5 15ARH05", " - drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge", " - drm/amd/display: Fix flip-done timeouts on mode1 reset", " - drm/amd/display: Fix missing DCE check in", " dm_gpureset_toggle_interrupts()", " - drm/v3d: Reach the GMP through the hub registers on V3D 7.x", " - 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: imx219: Fix maximum frame length in lines", " - media: iris: Fix use IRQF_NO_AUTOEN when requesting the IRQ", " - media: marvell-cam: fix missing pci_disable_device() on remove", " - media: nuvoton: npcm-video: fix error handling in npcm_video_init()", " - 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: qcom: camss: Fix RDI streaming for CSID 680", " - media: qcom: camss: Fix RDI streaming for CSID GEN2", " - media: qcom: camss: Fix RDI streaming for CSID GEN3", " - media: rzg2l-cru: Skip ICnMC configuration when ICnSVC is used", " - media: synopsys: hdmirx: Fix HPD lane hold time", " - 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: v4l2-subdev: Fail {enable,disable}_streams and s_streaming nicely", " - media: vb2: use ssize_t for vb2_read/vb2_write", " - media: verisilicon: Export only needed pixels formats", " - media: vidtv: fix reference leak on failed device registration", " - media: vimc: fix reference leak on failed device registration", " - media: vpif_capture: fix OF node reference imbalance", " - ALSA: hda/realtek: Fix speakers on Lunnen Ground 14", " - ALSA: hda: codecs: hdmi: disable keep-alive before audio format change", " - wifi: brcmfmac: set F2 blocksize to 256 for BCM43752", " - wifi: ath11k: fix refcount leak in ath11k_ahb_fw_resources_init()", " - staging: rtl8723bs: fix inverted HT40 secondary channel offset", " - platform/loongarch: laptop: Explicitly reset bl_powered state when", " suspend", " - rust_binder: only print failure if error has source", " - rust: time: fix as_micros_ceil() to round correctly for negative Delta", " - rust: allow `clippy::unwrap_or_default` globally", " - objtool/rust: add one more `noreturn` Rust function for Rust 1.99.0", " - LoongArch: Fix address space mismatch in kexec command line lookup", " - LoongArch: Fix oops during single-step debugging", " - LoongArch: Move jump_label_init() before parse_early_param()", " - LoongArch: Retrieve CPU package ID from PPTT when available", " - x86/boot/compressed: Disable jump tables", " - uio_hv_generic: Bind to FCopy device by default", " - serial: sc16is7xx: implement gpio get_direction() callback", " - selftests: ntsync: correct CONFIG_NTSYNC name", " - tracing: Fix context switch counter truncation", " - 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()", " - mptcp: decrement subflows counter on failed passive join", " - mptcp: only set DATA_FIN when a mapping is present", " - mm/kmemleak: fix checksum computation for per-cpu objects", " - mm/huge_memory: set PG_has_hwpoisoned only after new folio head is", " established", " - ceph: fix refcount leak in ceph_readdir()", " - ceph: fix writeback_count leak in write_folio_nounlock()", " - ASoC: fsl: imx-card: Skip sysclk reset for active DAIs in shutdown", " - ASoC: fsl_sai: Fix spurious BCLK on resume by clearing BYP", " - io_uring/rw: fix missing ERESTARTSYS conversion in read paths", " - iommu/vt-d: Disallow SVA if page walk is not coherent", " - net: stmmac: intel: skip SerDes reconfig when rate is unchanged", " - net: pcs: xpcs: fix SGMII state reading", " - proc: Fix broken error paths for namespace links", " - s390/ptff: Export ptff_function_mask[]", " - smb: client: handle STATUS_STOPPED_ON_SYMLINK responses without a", " symlink target", " - ice: use READ_ONCE() to access cached PHC time", " - ovpn: hold peer before scheduling keepalive work", " - vsock/virtio: collapse receive queue under memory pressure", " - watchdog: s32g_wdt: remove incorrect options in watchdog_info struct", " - drm/amd/pm: fix amdgpu_pm_info power display units", " - drm/amd/pm: make pp_features read-only when scpm is enabled", " - drm/amdgpu/jpeg: fix jpeg_v4_0_3_is_idle detection", " - drm/amdgpu/jpeg: fix jpeg_v5_0_1_is_idle detection", " - drm/amdgpu/soc24: reset dGPU if suspend got aborted", " - drm/amdgpu: fix resource leak on ACP reset timeout", " - drm/amd/pm: fix smu13 power limit range calculation", " - drm/amdgpu: fix check in amdgpu_hmm_invalidate_gfx", " - drm/xe/uapi: Reject coh_none PAT index for CPU_ADDR_MIRROR", " - net: qrtr: ns: Raise node count limit to 512", " - drm/amd/display: Fix DTB DTO updates breaking live pixel rate sources", " - audit: widen ino fields to u64", " - audit: use 'unsigned int' instead of 'unsigned'", " - xfs: don't replace the wrong part of the cow fork", " - netfilter: nf_tables: remove register tracking infrastructure", " - drm: drop lib from header search path.", " - SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlists", " - SUNRPC: Return an error from xdr_buf_to_bvec() on overflow", " - SAUCE: Revert \"mm/sparse-vmemmap: fix vmemmap accounting underflow\"", " - mm/sparse-vmemmap: fix vmemmap accounting underflow", " - mmc: vub300: rename probe error labels", " - net: mana: Optimize irq affinity for low vcpu configs", " - bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c", " - bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()", " - pmdomain: imx93-blk-ctrl: convert to devm_* only", " - rust: allow `suspicious_runtime_symbol_definitions` lint for Rust >=", " 1.98", " - rust: device: avoid trailing ; in printing macros", " - sched_ext: Skip ops.set_weight() for disabled tasks", " - sched_ext: Annotate ksyncs with __rcu in alloc/free_kick_syncs()", " - reset: spacemit: k3: fix USB2 ahb reset", " - wifi: cfg80211: reject empty PMSR peer lists", " - ASoC: amd: acp: Fix linker error with SDCA quirks", " - [Config] Adjust config SND_SOC_ACPI_AMD_SDCA_QUIRKS", " - sched_ext: Enable tick for finite slices on nohz_full", " - Bluetooth: mgmt: Translate HCI reason in Device Disconnected event", " - riscv: Gate FUNCTION_ALIGNMENT_4B on DYNAMIC_FTRACE", " - spi: cadence-quadspi: Fix indirect write timeout when DMA read mode is", " enabled", " - drm/xe: Assign queue name in time for drm_sched_init", " - drm/xe: add WQ_PERCPU to alloc_workqueue users", " - selftests: netconsole: only restore MAC when it changed on resume", " - wifi: ath10k: fix skb leak on incomplete msdu during rx pop", " - wifi: ath12k: Fix low MLO RX throughput on WCN7850", " - iommu/amd: Fix nested domain leak", " - arm_mpam: Fix software reset values of MPAMCFG_PRI", " - arm_mpam: Fix MPAMCFG_MBW_PBM register setting", " - hwmon: Drop unused i2c driver_data", " - hwmon: Use named initializers for arrays of i2c_device_data", " - hwmon: (pmbus/max34440): add support adpm12250", " - hwmon: (pmbus/max34440) block unsupported VIN and IIN limit registers", " - drm/i915/backlight: Remove DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check for", " DPCD backlight", " - selftests/net: Fix tun IPv6 test addresses to avoid 6to4 range", " - geneve: fix hint header definition wrt endianness", " - geneve: ensure the skb is writable before fixing its headers", " - accel: ethosu: Handle U85 internal chaining buffer", " - selftests: drv-net: convert so_txtime to drv-net", " - cifs: prevent readdir from changing file size due to stale directory", " metadata", " - wifi: mt76: fix airoha_npu dependency tracking", " - [Config] Fix config dependencies for MT76_NPU", " - drm/panel: ilitek-ili9882t: fix unmet dependency for", " DRM_PANEL_ILITEK_ILI9882T", " - iomap: fix incorrect did_zero setting in iomap_zero_iter()", " - mpls: Set rt->rt_nhn just before returning from mpls_nh_build_multi().", " - LoongArch: BPF: Zero-extend signed ALU32 div/mod results", " - bnge/bng_re: fix ring ID widths", " - pidfs: make pidfs_ino_lock static", " - LoongArch: BPF: Fix memory leak in bpf_jit_free()", " - drm/exynos: fbdev: Remove offset into screen_buffer", " - drm/tegra: fbdev: Remove offset into framebuffer memory", " - drm/i915/cdclk: Fix up CDCLK_FREQ_DECIMAL without a full PLL re-enable", " - drm/amd/pm: re-enable MC access after PrepareMp1ForUnload on SMU V15", " APUs", " - bitmap: add test_zero_nbits()", " - drm/xe: Add compact-PT and addr mask handling for page reclaim", " - drm/amd/display: Restore periodic detection for DCN35", " - drm/amdgpu: Respect placement requirements in amdgpu_gtt_mgr functions", " - drm/amdkfd: Use exclusive bounds for SVM split alignment checks", " - drm/i915/mtl+: Enable PPS before PLL", " - drm/xe/oa: Fix offset alignment for MERT WHITELIST_OA_MERT_MMIO_TRG", " - drm/xe/nvm: fix writable override for CRI", " - drm/amdgpu: Check for multiplication overflow in checkpoint stack size", " - drm/amdkfd: Guard m->cp_hqd_eop_control setting by", " q->eop_ring_buffer_size", " - drm/amdkfd: free MQD managers on DQM init failures", " - drm/amd/display: set MSA MISC1 bit 6 when using VSC SDP for DCE 11.x", " - drm/amdgpu: add the doorbell index input for suspending userq", " - drm/amdgpu: remove deadlocks from amdgpu_userq_pre_reset", " - drm/amd: Create a device link between APU display and XHCI devices", " - drm/pagemap: Clear driver-provided PFNs from migration PFN array", " - mm: add gpu active/reclaim per-node stat counters (v2)", " - drm/ttm: use gpu mm stats to track gpu memory allocations. (v4)", " - drm/ttm: Fix GPU MM stats during pool shrinking", " - drm/ttm/pool: back up at native page order", " - drm/gpusvm: Zero HMM PFNs before scanning ranges", " - media: mali-c55: Add missing of_reserved_mem_device_release()", " - media: mali-c55: Disable pm_runtime on probe error", " - media: mali-c55: Power-off the peripheral in remove()", " - media: qcom: camss: Fix RDI streaming for CSID 340", " - media: rzv2h-ivc: Wait for frame end in stop_streaming", " - media: ti: vpe: Fix fwnode_handle leak in vip_probe_complete()", " - media: ti: vpe: Fix the error code of devm_request_irq()", " - media: uapi: rkisp: Correct name version enum", " - wifi: mt76: restrict NPU/PPE active checks to MMIO devices", " - LoongArch: Fix build errors due to wrong instructions for 32BIT", " - LoongArch: Increase TASK_STRUCT_OFFSET up to 2040 for 32BIT", " - firmware: stratix10-svc: fix teardown order in remove to prevent race", " - firmware: stratix10-svc: handle NO_RESPONSE in async poll", " - tracing: perf: Fix stale head for perf syscall tracing", " - 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\"", " - selftests: mptcp: userspace_pm: fix undefined variable port", " - m68k: avoid -Wunused-but-set-parameter in clear_user_page()", " - mm/memory-failure: trace: change memory_failure_event to ras subsystem", " - mm/slub: fix lost local objects when bulk remote free batch fills", " - mm/slab: fix a memory leak due to bootstrapping sheaves twice", " - drm/amdgpu: rework userq fence driver alloc/destroy", " - drm/amdgpu: rework userq fence signal processing", " - drm/amdgpu/gfx11: fix EOP interrupt routing for KQ and userq", " - drm/amdgpu/gfx12: fix EOP interrupt routing for KQ and userq", " - drm/amdgpu/mes11: set doorbell offset for suspending userq", " - selftests: drv-net: add missing kconfig for psp.py", " - mm/sparse-vmemmap: pass @pgmap argument to memory deactivation paths", " - mm/sparse-vmemmap: fix DAX vmemmap accounting with optimization", " - selftests: drv-net: cope with slow env in so_txtime.py test", " - selftests: drv-net: so_txtime: relax variance bounds", " - cifs: fix time_last_write stamp placement in setattr/truncate paths", " - cifs: consolidate time_last_write stamp into _cifsFileInfo_put()", " - Upstream stable to v6.18.41, v6.18.42, v6.18.43, v7.1.6, v7.1.7", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68480", " - x86/bugs: Make Safe-RET robust against interrupt injection", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68105", " - drm/amdgpu: Fix kernel panic during driver load failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68109", " - drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68114", " - drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68431", " - ksmbd: validate minimum PDU size for transform requests", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68138", " - net/sched: serialize qdisc_rtab_list against concurrent get/put", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68082", " - libceph: fix two unsafe bare decodes in decode_lockers()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68159", " - libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68163", " - mm/page_vma_mapped: fix device-private PMD handling", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68166", " - userfaultfd: prevent registration of special VMAs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68170", " - mptcp: fix stale skb->sk reference on subflow close", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68177", " - tracing: Delay module ref count for \"enable_event\" trigger", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68191", " - wifi: ath12k: fix NULL pointer dereference in rhash table destroy", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64586", " - wifi: brcmfmac: drain bus_reset work on device removal", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68208", " - media: ti: vpe: Fix the error code of devm_kzalloc() in", " vip_probe_slice()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68224", " - media: mali-c55: Fix possible ERR_PTR in enable_streams", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68237", " - drm/amdgpu/userq: fix indefinite fence wait during GPU reset", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68240", " - drm/gpusvm: publish dpagemap early to avoid device mapping leak on error", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68242", " - drm/i915/gt: Fix NULL deref on sched_engine alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68254", " - drm/i915/vrr: require valid min/max vfreq for VRR", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68436", " - drm/amd/display: use kvzalloc to allocate struct dc", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68447", " - drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68264", " - drm/xe/pt: Reset current_op in xe_pt_update_ops_init()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68265", " - drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68267", " - drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68273", " - drm/amdgpu: Fix context pstate override handling", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68274", " - drm/xe/guc: Fix buffer overflow in steered register list allocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68283", " - tracing: Fix use-after-free freeing trigger private data", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68286", " - drop_monitor: perform u64_stats updates under IRQ-disabled section", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68287", " - drop_monitor: fix size calculations for 64-bit attributes", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68288", " - net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68289", " - tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68291", " - idpf: fix max_vport related crash on allocation error during init", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68303", " - drm/vc4: hvs/v3d: Fix null dereference in unbind", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68312", " - cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain", " paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68316", " - accel: ethosu: Fix element size accounting for cmd stream validation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68322", " - rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68440", " - net: txgbe: fix heap overflow when reading module EEPROM", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68323", " - tipc: serialize udp bearer replicast list updates", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68441", " - net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68337", " - bpf: Reject redirect helpers without a bpf_net_context", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68345", " - arm_mpam: guard MBWU state before adding it to garbage", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68347", " - iommu/amd: Fix IRQ unsafe locking in gdom allocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68375", " - bnxt_en: Handle partially initialized auxiliary devices", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68382", " - drm/xe/guc: Hold device ref until queue teardown completes", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68383", " - drm/xe/guc: Keep scheduler timeline name alive", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68390", " - Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68399", " - bpf: Fix UAF in sock clone early bailouts", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68404", " - wifi: cfg80211: use wiphy work for socket owner autodisconnect", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64581", " - xfrm: fix sk_dst_cache double-free in xfrm_user_policy()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68093", " - KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision", " after hotplug", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68367", " - usb: gadget: f_tcm: synchronize delayed set_alt with teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68164", " - mm/damon/core: disallow overlapping input ranges for damon_set_regions()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68165", " - mm/damon/core: validate ranges in damon_set_regions()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68095", " - fuse-uring: fix race between registration and connection abortion", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68096", " - audit: fix recursive locking deadlock in audit_dupe_exe()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68147", " - fscrypt: Avoid dynamic allocation in fscrypt_get_devices()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68097", " - ksmbd: validate ACE size against SID sub-authorities", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68098", " - ksmbd: bound DACL dedup walk to copied ACEs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68099", " - ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68100", " - ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68173", " - ublk: wait on ublk_dev_ready() instead of ub->completion", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68104", " - drm/amdgpu: invoke pm_genpd_remove() before freeing genpd", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68106", " - drm/amdgpu: fix division by zero with invalid uvd dimensions", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68429", " - drm/dp_mst: Handle torn-down topology gracefully in", " drm_dp_mst_topology_queue_probe()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68107", " - drm/amdgpu/vcn4: avoid rereading IB param length", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68108", " - drm/amdgpu/vce: fix integer overflow in image size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68110", " - drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68111", " - drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68112", " - drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68430", " - drm/amdgpu/gfx8: drop unecessary BUG_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68113", " - drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68246", " - drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68115", " - drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68116", " - vxlan: mdb: Fix source list corruption on a failed replace", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68117", " - tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68118", " - tcp: challenge ACK for non-exact RST in SYN-RECEIVED", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68119", " - tcp: initialize standalone TCP-AO response padding", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68120", " - rtase: Workaround for TX hang caused by hardware packet parsing", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68121", " - pppoe: reload header pointer after dev_hard_header()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68122", " - ovpn: fix peer refcount leak in TCP error paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68123", " - openvswitch: fix GSO userspace truncation underflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68124", " - mctp: serial: handle zero-length frames to prevent rx buffer overflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68125", " - mac802154: llsec: reject frames shorter than the authentication tag", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68126", " - mac802154: hold an interface reference across the scan worker", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68127", " - ila: reload IPv6 header after pskb_may_pull in checksum adjust", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68128", " - ice: reject out-of-range ptype in ice_parser_profile_init", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68129", " - gve: fix Rx queue stall on alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68130", " - ksmbd: defer destroy_previous_session() until after NTLM authentication", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68131", " - rbd: Reset positive result codes to zero in object map update path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68132", " - super: fix emergency thaw deadlock on frozen block devices", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68133", " - ice: fix PTP Call Trace during PTP release", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68134", " - ptp: ptp_s390: Add missing facility check", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68135", " - net: hip04: fix RX buffer leak on build_skb failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68136", " - net: gro: fix double aggregation of flush-marked skbs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68137", " - net/x25: fix use-after-free in x25_kill_by_neigh()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68139", " - net/mlx5e: Use sender devcom for MPV master-up", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68140", " - net/iucv: fix use-after-free of a severed iucv_path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68141", " - net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68142", " - geneve: require CAP_NET_ADMIN in the device netns for changelink", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68143", " - net: slip: serialize receive against buffer reallocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68432", " - vxlan: require CAP_NET_ADMIN in the device netns for changelink", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68144", " - phonet: pep: fix use-after-free in pep_get_sb()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68145", " - iomap: fix out-of-bounds bitmap_set() with zero-length range", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68146", " - ftrace: Add global mutex to serialize trace_parser access", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68148", " - fscrypt: Add missing superblock check in find_or_insert_direct_key()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68149", " - fs: preserve ACL_DONT_CACHE state in forget_cached_acl()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68150", " - fs/super: fix emergency thaw double-unlock of s_umount", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68151", " - binfmt_elf_fdpic: only honour the first PT_INTERP", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68152", " - amt: fix use-after-free in AMT delayed works", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68153", " - libceph: remove debugfs files before client teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68154", " - libceph: reject zero bucket types in crush_decode", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68155", " - libceph: Reject monmaps advertising zero monitors", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68156", " - libceph: refresh auth->authorizer_buf{,_len} after authorizer update", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68157", " - libceph: guard missing CRUSH type name lookup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68158", " - libceph: Fix multiplication overflow in decode_new_up_state_weight()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68433", " - libceph: bound get_version reply decode to front len", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68160", " - ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68161", " - sctp: close UDP tunnel sockets during netns teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68162", " - sctp: avoid auth_enable sysctl UAF during netns teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64564", " - sctp: don't free the ASCONF's own transport in DEL-IP processing", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68168", " - afs: Fix afs_edit_dir_remove() to get, not find, block 0", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68169", " - mptcp: pm: userspace: fix use-after-free in get_local_id", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68172", " - arm64: make huge_ptep_get handled unaligned addresses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68174", " - tracing: Fix union collision of module and refcnt for dynamic events", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68175", " - tracing: Fix resource leak on mmiotrace trace_pipe close", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68176", " - tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68178", " - misc: nsm: pin the module while the device is open", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68179", " - misc: nsm: only unlock nsm_dev on post-lock error paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68180", " - intel_th: fix MSC output device reference leak", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68181", " - mei: bus: access mei_device under device_lock on cleanup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68434", " - serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR", " platforms", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68182", " - comedi: comedi_parport: deal with premature interrupt", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68183", " - firmware: stratix10-svc: fix memory leaks and list corruption bugs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64563", " - rhashtable: clear stale iter->p on table restart", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68184", " - cdrom: fix stack out-of-bounds read in CDROMVOLCTRL", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68186", " - binfmt_misc: set have_execfd only once the interpreter is opened", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68187", " - exec: fix unsigned loop counter wrap in transfer_args_to_stack()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68188", " - Bluetooth: RFCOMM: Fix session UAF in set_termios", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68189", " - Bluetooth: hci_sync: Protect UUID list traversal", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68190", " - staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68192", " - wifi: brcmfmac: make release_scratchbuffers idempotent", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68193", " - wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68194", " - wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68195", " - wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68196", " - wifi: wilc1000: validate assoc response length before subtracting header", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68197", " - wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-", " oper", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68198", " - wifi: ath6kl: fix use-after-free in aggr_reset_state()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68199", " - wifi: ath6kl: fix OOB access from firmware ADDBA window size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68200", " - ALSA: timer: don't re-enter an instance callback that is still running", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68201", " - ALSA: timer: drain a slave's callback before its master detaches it", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68202", " - ALSA: seq: close a re-opened queue timer in the destructor", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68203", " - media: vivid: fix cleanup bugs in vivid_init()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68204", " - media: vivid: check for vb2_is_busy() when toggling caps", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68205", " - media: v4l2-fwnode: Fix subdev owner overwritten in", " v4l2_async_register_subdev_sensor()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68206", " - media: v4l2-ctrls: validate HEVC active reference counts", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68207", " - media: ti: vpe: unwind v4l2 device registration on probe error", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68209", " - media: sun4i-csi: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68210", " - media: stm32: dcmi: unregister notifier on probe failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68211", " - media: stm32-dcmipp: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68212", " - media: saa7134: Fix a possible memory leak in saa7134_video_init1", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68213", " - media: rtl2832_sdr: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68214", " - media: rtl2832: fix use-after-free in rtl2832_remove()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68215", " - media: radio-si476x: Unregister v4l2_device on probe failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68216", " - media: pwc: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68217", " - media: pwc: Drain fill_buf on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68218", " - media: pci: dm1105: Free allocated workqueue", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68219", " - media: nxp: imx8-isi: Fix potential out-of-bounds issues", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68220", " - media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and", " pipe", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68221", " - media: nuvoton: npcm-video: fix memory leaks in probe and remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68222", " - media: msi2500: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68223", " - media: meson: vdec: Fix memory leak in error path of vdec_open", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68225", " - media: i2c: alvium: fix critical pointer access in alvium_ctrl_init", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68226", " - media: cx23885: add ioremap return check and cleanup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68227", " - media: cx231xx: fix devres lifetime", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68228", " - media: chips-media: wave5: Move src_buf Removal to finish_encode", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68229", " - media: cedrus: skip invalid H.264 reference list entries", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68230", " - media: amlogic-c3: Add validations for ae and awb config", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68231", " - media: airspy: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68232", " - drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68445", " - drm/vc4: Prevent shader BO mappings from becoming writable", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68446", " - drm/vmwgfx: Validate vmw_surface_metadata::array_size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68233", " - drm/vc4: Shut down BO cache timer before teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68234", " - drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68235", " - drm/amd/display: dce100: skip non-DP stream encoders for DP MST", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68236", " - drm/amd/display: set new_stream to NULL after release", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68238", " - drm/amdgpu: Release VFCT ACPI table reference", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68239", " - drm/ttm: Account for NULL and handle pages in ttm_pool_backup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68241", " - drm/i915/mst: limit DP MST ESI service loop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68243", " - drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68244", " - drm/i915/gem: Do not leak siblings[] on proto context error", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68245", " - drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68247", " - drm/i915/bios: range check LFP Data Block panel_type2", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68248", " - drm/i915: Return NULL on error in active_instance", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68249", " - drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68250", " - drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68251", " - drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68252", " - drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68253", " - drm/i915/hdcp: check streams[] bounds before overflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68255", " - drm/virtio: bound EDID block reads to the response buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68256", " - drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path", " leaks prev_sink reference", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68257", " - drm/amdkfd: fix 32-bit overflow in CWSR total size calculation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68258", " - drm/amdkfd: Check bounds on CRIU restore queue type and mqd size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68259", " - drm/amdkfd: Check bounds in allocate_event_notification_slot", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68260", " - drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68261", " - drm/imagination: fix error checking of pvr_vm_context_lookup()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68262", " - drm/imagination: Fix user array stride in pvr_set_uobj_array()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68263", " - drm/imagination: Fix double call to drm_sched_entity_fini()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68266", " - drm/xe: Hold a dma-buf reference for imported BOs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68268", " - drm/xe: Return error on non-migratable faults requiring devmem", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68269", " - drm/i915/gem: Add missing nospec on parallel submit slot", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68270", " - drm/sysfb: Avoid possible truncation with calculating visible size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68271", " - drm/nouveau: fix reversed error cleanup order in ucopy functions", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68272", " - drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68275", " - drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68276", " - drm/amdgpu/gfx: fix cleaner shader IB buffer overflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68277", " - drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68437", " - drm/imagination: Fit paired fragment job in the correct CCCB", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68278", " - drm/dp/mst: fix buffer overflows in sideband chunk accumulation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68279", " - drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68280", " - drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68281", " - drm/imagination: Count paired job fence as dependency in prepare_job()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68282", " - drm/rockchip: analogix_dp: Add missing error check for", " platform_get_resource()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68284", " - bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68290", " - rds: tcp: unregister sysctl before tearing down listen socket", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68292", " - ice: prevent tstamp ring allocation for non-PF VSI types", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68293", " - net/mlx5: Fix MCIA register buffer overflow on 32 dword reads", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68294", " - net: qrtr: restrict socket creation to the initial network namespace", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68296", " - net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64575", " - bpf: tcp: fix double sock release on batch realloc", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68297", " - tipc: fix u16 MTU truncation in media and bearer MTU validation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68298", " - drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68299", " - vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68300", " - sctp: auth: verify auth requirement when auth_chunk is NULL", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68301", " - net: hsr: fix memory leak on slave unregistration by removing synced", " VLANs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68302", " - amt: re-read skb header pointers after every pull", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68448", " - ovl: check access to copy_file_range source with src mounter creds", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68304", " - wifi: brcmfmac: fix 802.1X-SHA256 call trace warning", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68306", " - wifi: mt76: mt7996: fix possible NULL-pointer deref in", " mt7996_mcu_sta_bfer_eht()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68307", " - wifi: mt76: mt7925: fix crash in reset link replay", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68308", " - wifi: mt76: mt7996: check pointer returned by", " mt76_connac_get_he_phy_cap()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68439", " - wifi: mt76: mt7925: fix possible NULL-pointer deref in", " mt7925_mcu_bss_he_tlv()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68309", " - wifi: mt76: connac: fix possible NULL-pointer deref in", " mt76_connac_mcu_uni_bss_he_tlv()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68310", " - wifi: mt76: mt7915: guard HE capability lookups", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68311", " - wifi: mt76: mt7925: guard link STA in decap offload", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68313", " - tipc: fix infinite loop in __tipc_nl_compat_dumpit", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64576", " - nexthop: initialize extack in nh_res_bucket_migrate()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64577", " - gtp: check skb_pull_data() return in gtp1u_send_echo_resp()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68314", " - net: mctp i3c: clean up notifier and buses if driver register fails", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68315", " - sctp: validate stream count in sctp_process_strreset_inreq()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68317", " - pds_core: fix auxiliary device add/del races", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68318", " - pds_core: fix use-after-free on workqueue during remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68319", " - pds_core: fix deadlock between reset thread and remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68320", " - sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68321", " - net: txgbe: fix FDIR filter leak on remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68324", " - iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68325", " - iommu/amd: Bound the early ACPI HID map", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68326", " - wifi: mwifiex: bound uAP association event IEs to the event buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68327", " - wan: wanxl: Only reset hardware after BAR mapping", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68328", " - nfp: Check resource mutex allocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64574", " - wifi: mac80211: tear down new links on vif update error path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68329", " - iommu/amd: Wait for completion instead of returning early in", " iommu_completion_wait()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68330", " - net: airoha: Fix DMA direction for NPU mailbox buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68331", " - dpaa2-eth: put MAC endpoint device on disconnect", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68332", " - net: airoha: Fix potential use-after-free in airoha_ppe_deinit()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68333", " - dpaa2-switch: put MAC endpoint device on disconnect", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68334", " - rxrpc: fix io_thread race in rxrpc_wake_up_io_thread()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68335", " - rds: drop incoming messages that cross network namespace boundaries", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68336", " - bonding: fix devconf_all NULL dereference when IPv6 is disabled", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68338", " - net/packet: avoid fanout hook re-registration after unregister", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68339", " - Bluetooth: btusb: validate Realtek vendor event length", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68340", " - hwmon: occ: validate poll response sensor blocks", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68341", " - ovpn: fix use after free in unlock_ovpn()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68342", " - ovpn: avoid putting unrelated P2P peer on socket release", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68343", " - smb: client: validate DFS referral PathConsumed", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68346", " - ALSA: hda: cs35l41: validate and free ACPI mute object", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68348", " - ASoC: tas2781: bound firmware description string parsing", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68450", " - btrfs: free mapping node on duplicate reloc root insert", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68442", " - btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68349", " - wifi: carl9170: fix buffer overflow in rx_stream failover path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68350", " - wifi: carl9170: fix OOB read from off-by-two in TX status handler", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68351", " - wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68352", " - wifi: ath6kl: fix OOB read from firmware IE lengths in connect event", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68353", " - wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68354", " - firewire: net: Fix fragmented datagram reassembly", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68355", " - wifi: ath11k: fix potential buffer underflow in", " ath11k_hal_rx_msdu_list_get()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68356", " - watchdog: airoha: Prevent division by zero when clock frequency is zero", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68357", " - watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68358", " - hwmon: (nzxt-kraken3) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68359", " - hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68443", " - hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68360", " - hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68361", " - hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68362", " - wifi: ath11k: fix NULL pointer dereference in", " ath11k_hal_srng_access_begin", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68363", " - wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware", " request", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68365", " - USB: serial: io_edgeport: cap received transmit credits", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68366", " - usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64583", " - usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before", " teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68368", " - usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68369", " - usb: gadget: printer: fix infinite loop in printer_read()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64584", " - usb: gadget: f_midi: cancel pending IN work before freeing the midi", " object", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68370", " - usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68371", " - usb: musb: omap2430: Do not put borrowed of_node in probe", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68373", " - wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68374", " - usb: core: sysfs: add lock to bos_descriptors_read()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64569", " - mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68376", " - sctp: fix auth_hmacs array size in struct sctp_cookie", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68377", " - net/sched: act_tunnel_key: Defer dst_release to RCU callback", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68378", " - dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68379", " - tcp: fix TIME_WAIT socket reference leak on PSP policy failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68380", " - accel/amdxdna: Fix use-after-free of mm_struct in job scheduler", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64578", " - ksmbd: validate compound request size before reading StructureSize2", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68381", " - ksmbd: pin conn during async oplock break notification", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68384", " - drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68385", " - s390/checksum: Fix csum_partial() without vector facility", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68386", " - bpf, sockmap: Reject unhashed UDP sockets on sockmap update", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68387", " - can: raw: add locking for raw flags bitfield", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68388", " - smb/client: handle overlapping allocated ranges in fallocate", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68389", " - Bluetooth: hci_qca: Clear memdump state on invalid dump size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68391", " - Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68392", " - Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68393", " - Bluetooth: hci_sync: extend conn_hash lookup critical sections", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68394", " - Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64573", " - Bluetooth: qca: fix NVM tag length underflow in TLV parser", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68449", " - ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-", " scanning", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68395", " - ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is", " registered", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68396", " - scsi: core: wake eh reliably when using scsi_schedule_eh", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68397", " - net/iucv: take a reference on the socket found in afiucv_hs_rcv()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64572", " - ipv4: fib: free fib_alias with kfree_rcu() on insert error path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68398", " - ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68400", " - firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset", " calculation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68401", " - firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68402", " - wifi: cfg80211: bound element ID read when checking non-inheritance", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68403", " - wifi: brcmfmac: initialize SDIO data work before cleanup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68405", " - wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68406", " - wifi: cfg80211: validate PMSR FTM preamble range", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68407", " - wifi: nl80211: free RNR data on MBSSID mismatch", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68408", " - wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64571", " - wifi: p54: validate RX frame length in p54_rx_eeprom_readback()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68409", " - wifi: mac80211: defer link RX stats percpu free to RCU", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68410", " - wifi: libertas: fix memory leak in helper_firmware_cb()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64570", " - wifi: mac80211: fix fils_discovery double free on alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64568", " - wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68411", " - wifi: mac80211_hwsim: clamp virtio RX length before skb_put", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68412", " - wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68413", " - wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68414", " - wifi: cfg80211: cancel sched scan results work on unregister", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64579", " - xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64580", " - xfrm6: clear dst.dev on error to avoid double netdev_put in", " xfrm6_fill_dst()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64566", " - xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68415", " - xfrm: clear mode callbacks after failed mode setup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68416", " - mtd: fix double free and WARN_ON in add_mtd_device() error paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68417", " - RDMA/siw: publish QP after initialization", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68418", " - RDMA/irdma: Prevent user-triggered null deref on QP create", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68419", " - RDMA/irdma: Prevent rereg_mr for non-mem regions", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68420", " - xfrm: reject optional IPTFS templates in outbound policies", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68421", " - sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68444", " - firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68422", " - btrfs: fix root leak if its reloc root is unexpected in", " merge_reloc_roots()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64567", " - btrfs: reject free space cache with more entries than pages", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68425", " - IB/mad: Drop unmatched RMPP responses before reassembly", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68426", " - xfrm: fix stale skb->prev after async crypto steals a GSO segment", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64565", " - Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68427", " - gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68428", " - KVM: x86/mmu: Fix use-after-free on vendor module reload", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64562", " - KVM: nVMX: Hide shadow VMCS right after VMCLEAR", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64561", " - KVM: x86: Check for invalid/obsolete root *after* making MMU pages", " available", " * resolute: llvm-21-dev build-depends breaks cross-builds (LP: #2165407)", " - [Packaging] Fix cross-builds", " * Resolute Stable Update v6.18.40, v7.1.5 bugs (LP: #2165040)", " - accel/amdxdna: Allow forcing IOVA-based DMA via module parameter", " - SAUCE: bpf: Add missing NULL argument to zap_page_range_single", " - accel/amdxdna: Return ERR_PTR on dma_alloc_noncoherent failure", " - accel/amdxdna: Fix memory leak in amdxdna_iommu_alloc()", " * [SRU][HPE] Take Intel platform into account for old microcode checks", " (LP: #2161748)", " - x86/microcode: Refactor platform ID enumeration into a helper", " - x86/cpu: Add platform ID to CPU info structure", " - x86/cpu: Add platform ID to CPU matching structure", " - x86/microcode: Add platform mask to Intel microcode \"old\" list", " - x86/microcode: Do not access MSR_IA32_PLATFORM_ID when running as a", " guest", " * ice: E810 interface fails to initialize (ice_init_hw failed: -5) during", " NVM read (LP: #2163508)", " - ice: acquire NVM lock around each flash read", " * WWAN modem unresponsive after freeze on Dell systems with DW5826e", " (LP: #2163214)", " - platform/x86: dell-dw5826e: Add reset driver for DW5826e", " - platform/x86: dell-dw5826e: fix ACPI _DSM function index and bitmask", " usage", " - [Config] Add CONFIG_DELL_DW5826E_RESET=m", " * amdgpu panel self-refresh on dual-gpu laptops causes complete built-in", " panel freeze and severe system instability (LP: #2162904)", " - SAUCE: drm/amdgpu: Do not enter PSR if multiple displays are active", " * linux 7.0: dw9719 VCM never binds, disabling all IPU3 cameras (regression,", " fixed upstream) (LP: #2162045)", " - media: dw9719: Add back the I²C device id table", " * Fix TAS2783 SoundWire amp resume timeout >5s (LP: #2164967)", " - soundwire: Add a helper function to wait for device initialisation", " - ASoC: tas2783: Use new SoundWire enumeration helper", " - soundwire: Move wait for initialisation helper to header", " - ASoC: codecs: tas2783-sdw: Propagate regcache_sync() errors", " - ASoC: tas2783-sdw: drop stale regcache on uninitialized re-attach", " * Linux, Ubuntu, 24.04, System hangs for about 10 seconds when unplug", " external monitor cable on non TBT dock (LP: #2160082)", " - SAUCE: drm/i915/tc: Revert forced DP-alt connected workaround", " * Speakers not detected on HP systems with TI TAS2783 SoundWire amps", " (LP: #2164504)", " - ASoC: sdw_utils: Add missed component_name strings for TI amps", " * [TWL][Desktop] intel_dmc_wait_fw_load() merge to Ubuntu next release", " (LP: #2156316)", " - SAUCE: drm/i915/dmc: fix assert_dmc_loaded WARN during async firmware", " load", " * 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", " * Ethernet adapter unusable after suspend/resume on Advantech systems with", " Intel I226-V (LP: #2163375)", " - igc: fix netdev not re-attached after resume if interface is down", " * ice: fix stale -EBUSY on resume of Intel E810 (LP: #2162803)", " - ice: wait for reset completion in ice_resume()", " * idxd: crash-kernel NULL-pointer Oops in `destroy_workqueue()` breaks kdump", " on Intel DSA/IAA systems (LP: #2163062)", " - SAUCE: dmaengine: idxd: Do not call destroy_workqueue with null idxd->wq", " - SAUCE: dmaengine: idxd: fix duplicate memory frees on initialization", " error path.", " * [HP][ZBook Power 16 G11] Laptop freezed after upgrading the BIOS", " (LP: #2132119)", " - PCI/ASPM: Avoid L0s for Realtek RTS525A", " * Fix noise of audio output on more Dell QCx1255 models after reboot", " (LP: #2163293)", " - ALSA: hda/realtek - Add quirk for Dell Pro QC1255", " * Fix no audio input/output device on Dell WCL Slate platform with", " CirrusLogic audio solution (LP: #2160200)", " - ASoC: SDCA: fix the register to ctl value conversion for Q7.8 format", " - ASoC: SOF: ipc4-control: Use local copy of IPC message for sending", " * Fix no audio output and mute hotkey not working on HP ZBook 8 G2a", " (LP: #2158858)", " - ALSA: hda/realtek: Add inverted LED quirk for HP ZBook 8 G2a", " * Dock ethernet stops working after Thunderbolt dock unplug on Dell systems", " (LP: #2162704)", " - usb: core: port: Deattach Type-C connector on component unbind", " * USB-C alt mode dropped with false firmware bug warning on Dell systems", " (LP: #2162695)", " - Revert \"usb: typec: ucsi: Detect and skip duplicate altmodes from buggy", " firmware\"", " - Revert \"usb: typec: ucsi: Add duplicate detection to nvidia registration", " path\"", " - Revert \"usb: typec: ucsi: yoga_c630: Remove redundant duplicate altmode", " handling\"", " - usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware", " - usb: typec: ucsi: Add duplicate detection to nvidia registration path", " - usb: typec: ucsi: yoga_c630: Remove redundant duplicate altmode handling", " * Resolute update: upstream stable patchset 2026-08-20 (LP: #2164666)", " - crypto: algif_skcipher - force synchronous processing", " - crypto: sun4i-ss - Remove insecure and unused rng_alg", " - [Config] Remove unused CRYPTO_DEV_SUN4I_SS_PRNG", " - media: uvcvideo: Fix deadlock if uvc_status_stop is called from", " async_ctrl.work", " - bpf: Clear delta when clearing reg id for non-{add,sub} ops", " - selftests/bpf: Add tests for delta tracking when src_reg == dst_reg", " - selftests/bpf: Add tests for stale delta leaking through id reassignment", " - ALSA: hda/realtek: Add quirk for TongFang X6xx45xU", " - ALSA: hda: conexant: Remove mic bias threshold override", " - ALSA: hda: Fix cached processing coefficient verbs", " - ALSA: hda/realtek: Fix speakers on Legion Pro 7 16ARX8H with codec SSID", " 17aa:38a7", " - media: uvcvideo: Use hw timestaming if the clock buffer is full", " - media: uvcvideo: Avoid partial metadata buffers", " - media: uvcvideo: Fix buffer sequence in frame gaps", " - media: uvcvideo: Fix dev_sof filtering in hw timestamp", " - media: uvcvideo: Do not add clock samples with small sof delta", " - media: uvcvideo: Relax the constrains for interpolating the hw clock", " - 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: max310x: implement gpio_chip::get_direction()", " - serial: 8250_omap: clear rx_running on zero-length DMA completes", " - rxrpc: rxrpc_verify_data ensure rx_dec_buffer alloc", " - rxrpc: Fix socket notification race", " - rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)", " - rxrpc: Fix potential infinite loop in rxrpc_recvmsg()", " - rxrpc: Fix rxrpc_rotate_tx_rotate() to check there's something to rotate", " - rxrpc: Fix oob challenge leak in cleanup after notification failure", " - rxrpc: Fix ACKALL packet handling", " - rxrpc: Fix the reception of a reply packet before data transmission", " - rxrpc: Fix leak of connection from OOB challenge", " - afs: fix NULL pointer dereference in afs_get_tree()", " - afs: handle CB.InitCallBackState3 requests without a server record", " - afs: Fix uncancelled rxrpc OOB message handler", " - fbcon: fix NULL pointer dereference for a console without vc_data", " - fbcon: Use correct type for vc_resize() return value", " - openrisc: mm: Fix section mismatch between map_page and __set_fixmap", " - clocksource/drivers/sun5i: Handle error returns from", " devm_reset_control_get_optional_exclusive()", " - accel/amdxdna: Fix leak when pinning ubuf pages", " - drm/rockchip: dw_dp: Switch to drmm_kzalloc()", " - drm/rockchip: dw_dp: Fix null-ptr-deref in dw_dp_remove()", " - drm/rockchip: Test for imported buffers with drm_gem_is_imported()", " - drm/tidss: Drop extra drm_mode_config_reset() call", " - drm/gpusvm: Reject VMAs with VM_IO or VM_PFNMAP when creating SVM ranges", " - drm/gpuvm: Do not prepare NULL objects", " - 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", " - selftests/bpf: Fix off-by-one in bpf_cpumask_populate related selftest", " - dt-bindings: timer: Remove sifive,fine-ctr-bits property", " - drm/amd/pm: remove trailing semicolon from AMDGPU_PM_POLICY_ATTR macro", " - selftests/bpf: Use local type for flow_offload_tuple_rhash in", " xdp_flowtable", " - selftests/bpf: Use local type for bpf_fou_encap in test_tunnel_kern", " - Documentation: proc: fix section numbering in table of contents", " - arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Cobra", " - arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S", " - arm64: dts: qcom: ipq5424: Fix USB simple_bus_reg warnings", " - arm64: dts: qcom: sc8180x: Fix phy simple_bus_reg warning", " - 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: fix wrong pci_get_drvdata type in AER handlers", " - wifi: rtw88: fix wrong pci_get_drvdata type in AER handlers", " - wifi: rtw89: Correct data type for scan index to avoid infinite loop", " - wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA", " buffer", " - wifi: rtw89: add bounds check on firmware mac_id in link lookup", " - kconfig: fix potential NULL pointer dereference in conf_askvalue", " - soc: xilinx: Shutdown and free rx mailbox channel", " - pinctrl: mediatek: eint: Drop base from mtk_eint_chip_write_mask()", " - wifi: ath9k: fix OOB access from firmware tx status queue ID", " - ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint", " - Documentation/rv: Replace stale website link", " - 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", " - memory: tegra: Wire up system sleep PM ops", " - crypto: qat - fix heartbeat error injection", " - lib/vsprintf: Fix to check field_width and precision", " - dts: spacemit: set console baud rate on bpif3", " - pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path", " - dt-bindings: vendor-prefixes: Add Displaytech Ltd.", " - drm/gpuvm: take refcount on DRM device", " - drm/panel: Clean up S6E3HA2 config dependencies and fill help text", " - ARM: dts: rockchip: Add #{address,size}-cells to Chromium-based", " /firmware", " - arm64: dts: rockchip: Add #{address,size}-cells to Chromium-based", " /firmware", " - arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc", " - arm64: dts: imx8x-colibri: Correct SODIMM PAD settings", " - Revert \"arm64: dts: imx8mm-kontron: Add support for reading SD_VSEL", " signal\"", " - Revert \"arm64: dts: imx8mp-kontron: Add support for reading SD_VSEL", " signal\"", " - drm: renesas: rz-du: mipi_dsi: Fix return path on error", " - alarmtimer: Remove stale return description from alarm_handle_timer()", " - OPP: Fix race between OPP addition and lookup", " - crypto: ccp - Reverse the cleanup order in psp_dev_destroy()", " - crypto: ccp - Fix snp_filter_reserved_mem_regions() off-by-one", " - 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", " - ARM: multi_v7_defconfig: Correct QCOM_RPMH and QCOM_RPMHPD", " - nilfs2: fix backing_dev_info reference leak", " - media: qcom: camss: vfe: fix PIX subdev naming on VFE lite", " - media: iris: scale MMCX power domain on SM8250", " - media: venus: scale MMCX power domain on SM8250", " - iommu/amd: Fix a stale comment about which legacy mode is user visible", " - soc: mediatek: mtk-mmsys: Restore MT8167 routing masks lost during merge", " - bpf: fix crash in bpf_[set|remove]_dentry_xattr for negative dentries", " - uaccess: fix ignored_trailing logic in copy_struct_to_user()", " - arm64: dts: mediatek: mt8192-asurada: Move PCIe DMA bounce buffer to", " host", " - rust: alloc: fix `Vec::extend_with` SAFETY comment", " - clk: scmi: Fix clock rate rounding", " - arm64: dts: qcom: kodiak: Fix ICE reg size", " - arm64: dts: qcom: sm8450: Fix ICE reg size", " - drm/hisilicon/hibmc: add updating link cap in DP detect()", " - drm/hisilicon/hibmc: fix no showing when no connectors connected", " - drm/hisilicon/hibmc: move display contrl config to hibmc_probe()", " - 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()", " - scsi: hisi_sas: Add slave_destroy interface for v3 hw", " - 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)", " - IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier", " - RDMA/hns: Fix arithmetic overflow in calc_hem_config()", " - RDMA/mlx5: Fix UMR XLT cleanup on ODP populate failure", " - RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference", " - RDMA/hns: Initialize seqfile before creating file", " - drm/syncobj: Fix memory leak in drm_syncobj_find_fence()", " - selftests/bpf: Reject unsupported -k option in vmtest.sh", " - selftests/bpf: Fix test for refinement of single-value tnum", " - iommu/arm-smmu-qcom: Fix fastrpc compatible string in ACTLR client match", " table", " - selftests/mm: Fix resv_sz when parsing arm64 signal frame", " - firmware: arm_ffa: Honor partition info descriptor size", " - arm64: dts: imx8dxl-evk: Remove unnecessary PCIe EP properties", " - arm64: dts: imx8qxp-mek: Remove unnecessary PCIe EP vpcie-supply", " - arm64: dts: imx95-19x19-evk: Fix PCIe EP vpcie-supply", " - media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()", " - media: atomisp: gc2235: fix UAF and memory leak", " - staging: media: atomisp: fix loop shadowing in ia_css_stream_destroy()", " - riscv: dts: spacemit: set console baud rate on Milk-V Jupiter", " - firmware: smccc: Fix Arm SMCCC SOC_ID name call", " - firmware: arm_scmi: Read sensor config as 32-bit value", " - sysfs: clamp show() return value in sysfs_kf_read()", " - bitops: use common function parameter names", " - regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions", " - tools/nolibc: getopt: Fix potential out of bounds access", " - nilfs2: Fix return in nilfs_mkdir", " - net/sched: sch_drr: annotate data-races around cl->deficit", " - media: rockchip: rga: fix too small buffer size", " - firmware: arm_scmi: Fix OOB in scmi_power_name_get()", " - arm64: dts: qcom: lemans: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: monaco: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sc7180: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: kodiak: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8550: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8750: Add power-domain and iface clk for ice node", " - tracing: Bound synthetic-field strings with seq_buf", " - arm64: dts: qcom: lemans: Add eDP ref clock for eDP PHYs", " - writeback: drop now-unnecessary rcu_barrier() in", " cgroup_writeback_umount()", " - kernfs: fix suspicious RCU usage in kernfs_put()", " - 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", " - Revert \"treewide: Fix probing of devices in DT overlays\"", " - of: dynamic: Fix overlayed devices not probing because of fw_devlink", " - crypto: eip93 - fix reset ring register definition", " - cpufreq: Documentation: fix sampling_down_factor range", " - cpufreq: conservative: Simplify frequency limit handling", " - pwm: imx27: Fix variable truncation in .apply()", " - RDMA/mana_ib: Use ib_get_eth_speed for reporting port speed", " - bus: sunxi-rsb: Always check register address validity", " - pinctrl: spacemit: fix NULL check in spacemit_pin_set_config", " - 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/hns: Fix log flood after cmd_mbox failure", " - RDMA/counter: Fix incorrect port index in rdma_counter_init() error", " cleanup", " - pinctrl: meson: amlogic-a4: fix gpio output glitch", " - PM: sleep: Use complete() in device_pm_sleep_init()", " - 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", " - driver core: Fix missing jiffies conversion in", " deferred_probe_extend_timeout()", " - driver core: Guard deferred probe timeout extension with", " delayed_work_pending()", " - mtd: spi-nor: debugfs: Fix the flags list", " - mtd: spi-nor: Drop duplicate Kconfig dependency", " - ALSA: xen-front: Reset event channel state on stream clear", " - ALSA: xen-front: Connect event channel after stream prepare", " - ALSA: seq: oss: Fix UAF at handling events with embedded SysEx data", " - ALSA: seq: midi: Serialize output teardown with event_input", " - selftests: Fix Makefile target for nsfs", " - pinctrl: nuvoton: ma35d1: fix MFP register offset and pin table", " - pinctrl: cs42l43: Fix leaked pm reference on error path", " - pinctrl: cs42l43: Fix polarity on debounce", " - init/initramfs_test: wait_for_initramfs() before running", " - nvmet-tcp: fix page fragment cache leak in error path", " - nvmet-tcp: check return value of nvmet_tcp_set_queue_sock", " - nvme-pci: fix out-of-bounds access in nvme_setup_descriptor_pools", " - 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", " - iommu/amd: Fix premature break in init_iommu_one()", " - rtla/actions: Restore continue flag in actions_perform()", " - 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", " - bpftool: Fix typo in struct_ops map FD generation for light skeleton", " - libbpf: Fix UAF in strset__add_str()", " - ARM: tegra: Add #{address,size}-cells to Chromium-based /firmware", " - arm64: tegra: Add #{address,size}-cells to Chromium-based /firmware", " - 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", " - crypto: inside-secure/eip93 - Add check for devm_request_threaded_irq", " - crypto: tegra - Fix dma_free_coherent size error", " - crypto: tegra - Return ENOMEM when input buffer allocation fails for ccm", " - sched/deadline: Reject debugfs dl_server writes for offline CPUs", " - drm/msm/dp: fix HPD state status bit shift value", " - drm/msm/dp: Fix the ISR_* enum values", " - EDAC/igen6: Fix call trace due to missing release()", " - EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in", " skx_get_dimm_info", " - arm64: dts: st: Fix SAI addresses on stm32mp251", " - RDMA/umem: Add ib_umem_is_contiguous() stub for", " !CONFIG_INFINIBAND_USER_MEM", " - RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe", " - RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path", " - Revert \"media: venus: hfi_platform: Correct supported codecs for sc7280\"", " - 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", " - amba: use generic driver_override infrastructure", " - cdx: use generic driver_override infrastructure", " - Drivers: hv: vmbus: use generic driver_override infrastructure", " - rpmsg: use generic driver_override infrastructure", " - raid1: fix nr_pending leak in REQ_ATOMIC bad-block error path", " - bpf: fix BPF_PROG_QUERY OOB write and cgroup backward compat", " - selftests/bpf: add verification for BPF_PROG_QUERY attr size boundaries", " - libbpf: Skip hash computation when loader generation failed", " - libbpf: Skip endianness swap when loader generation failed", " - ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data", " writeback", " - spi: atmel: fix DMA channel and bounce buffer leaks", " - ASoC: rsnd: Fix RSND_SOC_MASK width to single nibble", " - NFSD: Fix delegation reference leak in nfsd4_revoke_states", " - ARM: imx3: Fix CCM node reference leak", " - HID: wiimote: Fix table layout and whitespace errors", " - wifi: ath12k: fix incorrect HT/VHT/HE/EHT MCS reporting in monitor mode", " - wifi: ath12k: fix NULL deref in change_sta_links for unready link", " - ata: libata: Fix ata_exec_internal()", " - ARM: imx31: Fix IIM mapping leak in revision check", " - x86/cpu: Keep the PROCESSOR_SELECT menu together", " - nvdimm/btt: Handle preemption in BTT lane acquisition", " - scsi: Revert \"scsi: Fix sas_user_scan() to handle wildcard and multi-", " channel scans\"", " - bpf: Reject exclusive maps as inner maps in map-in-map", " - libbpf: Reject non-exclusive metadata maps in the signed loader", " - libbpf: Skip initial_value override on signed loaders", " - libbpf: Skip max_entries override on signed loaders", " - 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", " - driver core: Use system_percpu_wq instead of system_wq", " - bpf: Reject exclusive maps for bpf_map_elem iterators", " - tick/sched: Fix TOCTOU in nohz idle time fetch", " - lib/test_meminit: use && for bools", " - riscv: dts: sophgo: sg2044: use hex for CPU unit address", " - riscv: dts: sophgo: sg2042: use hex for CPU unit address", " - configfs_lookup(): don't leave ->s_dentry dangling on failure", " - lockdep/selftests: Restore migrate_disable() state on PREEMPT_RT", " - lockdep/selftests: Restore sched_rt_mutex state on PREEMPT_RT", " - ext4: fix fast commit wait/wake bit mapping on 64-bit", " - drm/amdgpu: set sub_block_index for mca ras sub-blocks", " - bpftool: Use libbpf error code for flow dissector query", " - vhost: fix vhost_get_avail_idx for a non empty ring", " - iommu/vt-d: Fix RB-tree corruption in probe error path", " - perf/x86/amd/core: Always use the NMI latency mitigation", " - perf/x86/intel/uncore: Fix discovery unit lookup for multi-die systems", " - perf/x86/amd/uncore: Use Node ID to identify DF and UMC domains", " - xfrm: fix NAT-related field inheritance in SA migration", " - cxl/fwctl: Fix __fortify_panic", " - drm/amdkfd: always resume_all after suspend_all", " - of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array()", " fails", " - ocfs2: rebase copied fsdlm LVB pointers in locking_state", " - lib: kunit_iov_iter: repeatedly call alloc_pages_bulk()", " - 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: 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", " - netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock", " - ALSA: usb-audio: qcom: Initialize offload control return value", " - x86/cpu: Remove obsolete aperfmperf_get_khz() declaration", " - netfilter: conntrack: revert ct extension genid infrastructure", " - netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper", " is pptp", " - RDMA/hfi1: Open-code rvt_set_ibdev_name()", " - IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()", " - ALSA: hda: fix Kconfig dependency of HD Audio PCI", " - RDMA/irdma: Fix OOB read during CQ MR registration", " - RDMA/irdma: Initialize iwmr->access during MR registration", " - arm64: dts: imx8mp-kontron: Reduce EERAM SPI clock frequency", " - arm64: dts: imx95: Correct PCIe outbound address space configuration", " - arm64: dts: lx2162a-clearfog: use rev2 SoC dtsi", " - arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio codec as", " well", " - arm64: dts: imx8mp-kontron: Fix GPIO for display power switch", " - bpf: Clear rb node linkage when freeing bpf_rb_root", " - bpf: Check tail zero of bpf_map_info", " - 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: cpu_ops: Change return value type of cpu_is_stopped() to bool", " - riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe", " - ALSA: seq: Clear variable event pointer on read", " - bpf: Fix NMI/tracepoint re-entry deadlock on lru locks", " - kunit:tool: Don't write to stdout when it should be disabled", " - powerpc/8xx: implement get_direction() in cpm1", " - bpf: Fix NULL pointer dereference in bpf_task_from_vpid()", " - ACPI: IPMI: Fix message kref handling on dead device", " - cpufreq: Documentation: fix conservative governor freq_step description", " - thermal: testing: reject missing command arguments", " - btrfs: don't force DIO writes to be serialized", " - IB/mlx5: Don't take the rereg_mr fallback without a new translation", " - IB/mlx5: Properly support implicit ODP rereg_mr", " - IB/mlx5: Remove unused mkc bits in mlx5r_umr_update_mr_page_shift()", " - IB/mlx5: Pull the pdn out of the depths of the umr machinery", " - IB/mlx5: Don't mangle the mr->pd inside the rereg callback", " - spi: ep93xx: fix double-free of zeropage on DMA setup failure", " - ASoC: amd: acp-sdw-legacy: Bound DAI link iteration", " - ASoC: amd: acp-sdw-sof: Bound DAI link iteration", " - firmware_loader: Fix recursive lock in device_cache_fw_images()", " - configfs: fix lockless traversals of ->s_children", " - watchdog: unregister PM notifier on watchdog unregister", " - pinctrl: qcom: Fix resolving register base address from device node", " - 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", " - ARM: configs: Drop duplicated CONFIG_EXT4_FS", " - wifi: mt76: mt7925: clean up DMA on probe failure", " - wifi: mt76: use kfree_rcu for offchannel link in mt76_put_vif_phy_link", " - wifi: mt76: mt7996: add missing max_remain_on_channel_duration", " - wifi: mt76: mt7925: fix stale pointer comparisons in change_vif_links", " - wifi: mt76: mt7925: keep TX BA state in the primary WCID", " - wifi: mt76: mt792x: skip MLD header rewrite for 802.3 encap TX", " - wifi: mt76: mt7925: validate skb length in testmode query", " - wifi: mt76: mt7996: Fix possible token leak in mt7996_tx_prepare_skb()", " - wifi: mt76: mt7996: Fix possible NULL pointer dereference in", " mt7996_mac_write_txwi_80211()", " - wifi: mt76: mt7996: fix reading zeroed info->control.flags after", " mt76_tx_status_skb_add()", " - wifi: mt76: mt7996: limit work in set_bitrate_mask", " - 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", " - wifi: mt76: mt7925: fix potential tx_retries underflow", " - wifi: mt76: mt7996: fix potential tx_retries underflow", " - btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()", " - ALSA: aloop: Drop superfluous break", " - gpio: mt7621: fix interrupt banks mapping on gpio chips", " - wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is", " reported", " - fbdev: sm501fb: Fix buffer errors in OF binding code", " - vfs: add FS_USERNS_DELEGATABLE flag and set it for NFS", " - hwmon: (it87) Clamp negative values to zero in set_fan()", " - btrfs: zoned: don't account data relocation space-info in statfs free", " space", " - Revert \"btrfs: fix the file offset calculation inside", " btrfs_decompress_buf2page()\"", " - btrfs: zoned: always set max_active_zones for zoned devices", " - btrfs: annotate lockless read of defrag_bytes in should_nocow()", " - btrfs: fix deadlock cloning inline extent when using flushoncommit", " - igc: skip RX timestamp header for frame preemption verification", " - ASoC: sma1307: Fix uevent string leaks in fault worker", " - IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified", " - NFSD: Handle layout stid in nfsd4_drop_revoked_stid()", " - 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", " - virtio: rtc: tear down old virtqueues before restore", " - virtio_console: read size from config space during device init", " - vduse: Requeue failed read to send_list head", " - tools/virtio: check mmap return value in vringh_test", " - vdpa/octeon_ep: Fix PF->VF mailbox data address calculation", " - vdpa/octeon_ep: fix IRQ-to-ring mapping in interrupt handler", " - ASoC: cs35l56: Fix missing calls to wm_adsp2_remove()", " - ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend fails", " - ext4: fix ERR_PTR(0) in ext4_mkdir()", " - tools: missed broadcast_neigh if_link uapi header", " - netlink: specs: rt-link: missed broadcast-neigh", " - bonding: 3ad: add lacp_strict configuration knob", " - bonding: 3ad: fix carrier when no usable slaves", " - 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()", " - vfio/qat: fix f_pos race in qat_vf_resume_write()", " - bpf: Tighten cgroup storage cookie checks for prog arrays", " - pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag", " - pinctrl: airoha: an7581: add missed gpio32 pin group", " - pinctrl: airoha: an7581: fix misprint in gpio19 pinconf", " - arm64: dts: allwinner: a523: Add missing GPIO interrupt", " - ASoC: cs35l56: Fix possible uninitialized value in", " cs35l56_spi_system_reset()", " - s390/process: Fix kernel thread function pointer type", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for", " non-serdev device", " - Bluetooth: eir: Fix stack OOB write when prepending the Flags AD", " - Bluetooth: hci_event: fix simultaneous discovery stuck in FINDING", " - Bluetooth: hci_core: Fix UAF in hci_unregister_dev()", " - Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path", " - Bluetooth: hci: validate codec capability element length", " - Bluetooth: vhci: validate devcoredump state before side effects", " - fs: efs: remove unneeded debug prints", " - RDMA/mlx5: Remove DCT restrack tracking", " - 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: SOF: Intel: hda-sdw-bpt: select SND_SOF_SOF_HDA_SDW_BPT properly", " - 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: dsa: qca8k: fix led devicename when using external mdio bus", " - 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", " - net: pfcp: allocate per-cpu tstats for PFCP netdevs", " - 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: Unregister cxl_acpi in cxl_test_init() error path", " - 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", " - ALSA: usb-audio: qcom: Guard sideband endpoint removal", " - ALSA: seq: Fix kernel heap address leak in bounce_error_event()", " - spi: xilinx: use FIFO occupancy register to determine buffer size", " - iommu: Avoid copying the user array twice in the full-array copy helper", " - 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", " - virtio_net: do not allow tunnel csum offload for non GSO packets", " - net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net/sched: sch_dualpi2: 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", " - net: watchdog: fix refcount tracking races", " - net: ethernet: mtk_wed: fix loading WO firmware for MT7986", " - net/sched: sch_dualpi2: Add missing module alias", " - bpf: Run generic devmap egress prog on private skb", " - net/mlx5: Check max_macs devlink param value against max capability", " - bpf: Fix setting retval to -EPERM for cgroup hooks not returning errno", " - octeontx2-af: npc: Fix size of entry2cntr_map", " - net: ethernet: mtk_wed: debugfs: correct index in wed_amsdu_show()", " - net: wwan: t7xx: check skb_clone in control TX", " - 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", " - net: bcmgenet: Use weighted round-robin TX DMA arbitration", " - net: airoha: Fix register index for Tx-fwd counter configuration", " - net: airoha: Fix debugfs new-tuple display for IPv4 ROUTE entries", " - kcm: use WRITE_ONCE() when changing lower socket callbacks", " - ALSA: seq: oss: Serialize readq reset state with q->lock", " - ALSA: seq: avoid stale FIFO cells during resize", " - 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: Fix typo in verify_umulti_link_info", " - selftests/bpf: Initialize operation name before use", " - bpf: Fix bpf_get/setsockopt to tos for ipv4-mapped ipv6 socket", " - udf: fix nls leak on udf_fill_super() failure", " - bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()", " - net: remove addr_len argument of recvmsg() handlers", " - sockmap: Fix use-after-free in udp_bpf_recvmsg()", " - 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", " - tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)", " - net: airoha: Fix always-true condition in PPE1 queue reservation loop", " - net: ethernet: oa_tc6: Remove FCS size in RX frame", " - ionic: Fix check in ionic_get_link_ext_stats", " - RDMA/bnxt_re: Free SRQ toggle page after firmware teardown", " - RDMA/bnxt_re: Avoid displaying the kernel pointer", " - RDMA/bnxt_re: Fail DBR related page allocation UAPIs if the feature is", " disabled", " - ksmbd: fix use-after-free in same_client_has_lease()", " - mfd: rsmu: Fix page register setup", " - mfd: cs42l43: Sanity check firmware size", " - ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write", " - 9p: avoid returning ERR_PTR(0) from mkdir operations", " - eventpoll: rename ep_remove_safe() back to ep_remove()", " - eventpoll: expand top-of-file overview / locking doc", " - eventpoll: rename attach_epitem() to ep_attach_file()", " - 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", " - i3c: master: svc: Fix missed IBI after false SLVSTART on NPCM845", " - staging: nvec: fix use-after-free in nvec_rx_completed()", " - perf debuginfo: Fix libdw API contract violations", " - coresight: cti: Fix DT filter signals silently ignored", " - soundwire: don't program SDW_SCP_BUSCLOCK_SCALE on a unattached", " Peripheral", " - soundwire: fix bug in sdw_add_element_group_count found by syzkaller", " - coresight: ete: Always save state on power down", " - 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", " - perf sched: Add missing mmap2 handler in timehist", " - PCI: loongson: Do not ignore downstream devices on external bridges", " - rust: alloc: fix assert in `Vec::reserve` doc test", " - bus: mhi: ep: Fix potential deadlock in mhi_ep_reset_worker()", " - coresight: fix missing error code when trace ID is invalid", " - clk: qcom: cmnpll: Account for reference clock divider", " - phy: phy-can-transceiver: Check driver match and driver data against", " NULL", " - perf pmu: Skip test on Arm64 when #slots is zero", " - clk: at91: sam9x7: Fix gmac_gclk clock definition", " - soundwire: intel_ace2x: release bpt_stream when close it", " - coresight: Fix source not disabled on idr_alloc_u32 failure", " - mailbox: mpfs: fix check for syscon presence in mpfs_mbox_inbox_isr()", " - mailbox: mtk-adsp: fix UAF during device teardown", " - PCI: dwc: Fix signedness bug in fault injection test code", " - perf build-id: Fix off-by-one bug when printing kernel/module build-id", " - 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", " - perf test amd ibs: Fix incorrect kernel version check", " - gpib: Fix inappropriate ioctl error return", " - char: tlclk: fix use-after-free in tlclk_cleanup()", " - gpib: fix double decrement of descriptor_busy in command_ioctl()", " - clk: renesas: rzg2l: Rename iterator in for_each_mod_clock() to avoid", " shadowing", " - powerpc tools perf: Initialize error code in auxtrace_record_init", " function", " - PCI: qcom: Disable ASPM L0s for SA8775P", " - perf header: Sanity check HEADER_EVENT_DESC attr.size before swap", " - 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", " - drm/amd/display: Add missing kdoc for ALLM parameters", " - thunderbolt: debugfs: Fix margining error counter buffer leak", " - dmaengine: imx-sdma: Refine spba bus searching in probe", " - dt-bindings: dma: nvidia,tegra186-gpc-dma: Make reset optional", " - perf: Fix off-by-one stack buffer overflow in kallsyms__parse()", " - perf annotate: Fix crashes on empty annotate windows", " - perf tools: Guard test_bit from out-of-bounds sample CPU", " - perf sched: Fix thread reference leak in latency_switch_event", " - perf tools: Add bounds check to cpu__get_node()", " - perf sched: Cap max_cpu at MAX_CPUS in timehist sample processing", " - perf sched: Fix register_pid() overflow, strcpy, and BUG_ON", " - perf mmap: Guard cpu__get_node() return in aio_bind()", " - perf stat: Bounds-check CPU index in topology aggregation callbacks", " - perf c2c: Bounds-check CPU and node IDs before bitmap and array access", " - perf c2c: Bounds-check CPU IDs in setup_nodes() topology loop", " - perf sched: Clean up idle_threads entry on init failure", " - perf sched: Use thread__put() in free_idle_threads()", " - perf sched: Replace BUG_ON and add NULL checks in replay event helpers", " - perf mmap: Fix NULL deref in aio cleanup on alloc failure", " - perf stat: Introduce perf_env__get_cpu_topology() to guard NULL env->cpu", " - perf c2c: Fix use-after-free in he__get_c2c_hists() error path", " - perf timechart: Fix cpu2y() OOB read on untrusted CPU index", " - perf tools: Fix int16_t truncation of max_cpu_num in set_max_cpu_num()", " - dt-bindings: clock: qcom: Add X1P42100 camera clock controller", " - clk: qcom: camcc-x1e80100: Add support for camera QDSS debug clocks", " - mshv: add bounds check on vp_index in mshv_intercept_isr()", " - dmaengine: qcom: gpi: set DMA_PRIVATE capability", " - dmaengine: Fix possible use after free", " - dmaengine: dma-axi-dmac: Properly free struct axi_dmac_desc", " - dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor", " - clk: qcom: a53: Corrected frequency multiplier for 1152MHz", " - sunrpc: Fix error handling in rpc_sysfs_xprt_switch_add_xprt_store()", " - pNFS/filelayout: fix cheking if a layout is striped", " - 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", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in", " pg_get_mirror_count_write", " - PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro", " - pwm: rzg2l-gpt: Add missing newlines to dev_err_probe() messages", " - PCI: meson: Propagate devm_add_action_or_reset() failure", " - PCI: meson: Add missing remove callback", " - fs/ntfs3: resize log->one_page_buf when adopting on-disk page size", " - platform/x86/intel/vsec: Decouple add/link helpers from PCI", " - platform/x86/intel/vsec: Switch exported helpers from pci_dev to device", " - platform/x86/intel/vsec: Return real error codes from registration path", " - platform/x86/intel/vsec: Restore BAR fallback for header walk", " - perf tools: Fix get_max_num() size_t underflow on empty sysfs file", " - perf tools: Use scnprintf() in cpu_map__snprint() to prevent overflow", " - perf tools: Use perf_env__get_cpu_topology() in machine__resolve()", " - PCI: rcar-host: Remove unused LIST_HEAD(res)", " - perf sched: Bounds-check prio before test_bit() in timehist", " - perf sched: Fix idle-hist callchain display using wrong rb_first variant", " - perf bpf: Use scnprintf() in snprintf_hex() and", " synthesize_bpf_prog_name()", " - perf hists: Fix snprintf() in hists__scnprintf_title() UID filter path", " - xprtrdma: Fix ep kref imbalance on ADDR_CHANGE", " - xprtrdma: Initialize re_id before removal registration", " - xprtrdma: Check frwr_wp_create() during connect", " - xprtrdma: Document and assert reply-handler invariants", " - xprtrdma: Resize reply buffers before reposting receives", " - xprtrdma: Sanitize the reply credit grant after parsing", " - xprtrdma: Repost Receive buffers for malformed replies", " - xprtrdma: Return sendctx slot after Send preparation failure", " - perf s390: Fix TEXTREL in Python extension by compiling as PIC", " - perf cs-etm: Queue context packets for frontend", " - perf pmu: Fix pmu_id() heap underwrite on empty identifier file", " - perf pmu: Fix perf_pmu__parse_scale/unit() OOB access on empty sysfs", " file", " - tools lib api: Fix missing null termination in filename__read_int/ull()", " - perf symbols: Fix signed overflow in sysfs__read_build_id() size check", " - perf symbols: Bounds-check .gnu_debuglink section data", " - perf intel-pt: Fix snprintf size tracking bug in insn decoder", " - perf tools: Fix thread__set_comm_from_proc() on empty comm file", " - perf hwmon: Fix off-by-one null termination on sysfs reads", " - perf hwmon: Use scnprintf() in hwmon_pmu__for_each_event()", " - perf hwmon: Fix parse_hwmon_filename() strlcpy buffer overflow", " - perf symbols: Bounds-check descsz in sysfs__read_build_id() GNU fallback", " - perf hwmon: Guard label read against empty or failed reads", " - perf tools: Use snprintf() in dso__read_running_kernel_build_id()", " - tools lib api: Fix filename__write_int() writing uninitialized stack", " data", " - tools lib api: Fix mount_overload() snprintf truncation and toupper", " range", " - perf bpf: Add NULL check for btf__type_by_id() in", " synthesize_bpf_prog_name()", " - perf bpf: Fix map data leak in bpf_metadata_create() on alloc failure", " - perf bpf: Fix metadata leak in perf_env__add_bpf_info() on duplicate", " insert", " - perf symbols: Add bounds checks to elf_read_build_id() note iteration", " - perf symbols: Add bounds checks to read_build_id() note iteration in", " minimal build", " - dt-bindings: phy: sc8280xp-qmp-pcie: Disallow bifurcation register on", " Purwa", " - PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()", " - PCI: mediatek: Use actual physical address instead of virt_to_phys()", " - phy: freescale: phy-fsl-imx8qm-lvds-phy: Fix missing", " pm_runtime_disable() on probe error path", " - PCI: dwc: Avoid dwc_pcie_rasdes_debugfs_deinit() NULL dereference when", " no RAS DES capability", " - Revert \"PCI/MSI: Unmap MSI-X region on error\"", " - apparmor: fix shadowing of plabel that prevents cache from being updated", " - apparmor: fix race in unix socket mediation when peer_path is used", " - apparmor: fix refcount leak when updating the sk_ctx", " - security/apparmor/apparmorfs.c: conditionally compile", " get_loaddata_common_ref()", " - apparmor: check label build before no_new_privs test", " - apparmor: aa_label_alloc use aa_label_free on alloc failure", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [41/57]: apparmor-next 7.1:", " apparmor: fix rawdata_f_data implicit flex array\"", " - apparmor: fix rawdata_f_data implicit flex array", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [38/57]: apparmor-next 7.1:", " apparmor: grab ns lock and refresh when looking up changehat child", " profiles\"", " - apparmor: grab ns lock and refresh when looking up changehat child", " profiles", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [44/57]: apparmor-next 7.1:", " apparmor: fix potential UAF in aa_replace_profiles\"", " - apparmor: fix potential UAF in aa_replace_profiles", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor: fix NULL pointer dereference in", " unpack_pdb\"", " - apparmor: fix NULL pointer dereference in unpack_pdb", " - apparmor: remove or add symlinks to rawdata according to export_binary", " - apparmor: Fix return in ns_mkdir_op", " - apparmor: fail policy unpack on accept2 allocation failure", " - apparmor: aa_getprocattr free procattr leak on format failure", " - apparmor: put secmark label after secid lookup", " - apparmor: don't audit files pointing to aa_null.dentry", " - apparmor: fix uninitialised pointer passed to", " audit_log_untrustedstring()", " - i3c: mipi-i3c-hci: Preserve RUN bit when aborting DMA ring", " - i3c: master: Make hot-join workqueue freezable to block hot-join during", " suspend", " - i3c: master: Move rstdaa error suppression", " - i3c: master: Consolidate Hot-Join DAA work in the core", " - i3c: master: Ensure Hot-Join operations are stopped on shutdown", " - i3c: master: Defer new-device registration out of DAA caller context", " - i3c: master: Prevent reuse of dynamic address on device add failure", " - apparmor: fix label can not be immediately before a declaration", " - accel/ivpu: fix HWS command queue leak on registration failure", " - sparc: led: avoid trimming a newline from empty writes", " - perf symbols: Fix bswap copy-paste error for 32-bit ELF p_filesz", " - perf symbols: Validate p_filesz before use in filename__read_build_id()", " - perf symbols: Break infinite loop on zero-filled notes in", " sysfs__read_build_id()", " - perf tools: Add O_CLOEXEC to open() calls in DSO and ELF code", " - perf tools: Fix uninitialized pathname on uncompressed fallback in", " filename__decompress()", " - perf dso: Fix heap overflow in dso__get_filename() on decompressed path", " - perf dso: Set error code when open() fails on uncompressed fallback path", " - perf tools: Use snprintf() for root_dir path construction", " - perf hwmon: Fix fd check to accept fd 0 in hwmon_pmu__describe_items()", " - perf sched: Replace (void*)1 sentinel with proper runtime allocation", " - perf bpf: Validate func_info_rec_size and sub_id in", " synthesize_bpf_prog_name()", " - perf bpf: Reject oversized BPF metadata events that truncate header.size", " - perf bpf: Bounds-check array offsets in bpil_offs_to_addr()", " - perf cs-etm: Reject CPU IDs that would overflow signed comparison", " - gpio: mlxbf3: fail probe if gpiochip registration fails", " - drm/i915: clear CRTC color blob pointers after dropping refs", " - drm/xe: Fix wa_oob codegen recipe for external module builds", " - spi: dw: fix wrong BAUDR setting after resume", " - i3c: master: Update dev_nack_retry_count under maintenance lock", " - i3c: master: Add missing runtime PM get in dev_nack_retry_count_store()", " - ALSA: usb-audio: qcom: Free sideband sg_table objects", " - xfrm: annotate data-races around xfrm_policy_count[] and", " xfrm_policy_default[]", " - xfrm: validate selector family and prefixlen during match", " - perf machine: Use snprintf() for guestmount path construction", " - perf cs-etm: Validate num_cpu before metadata allocation", " - perf cs-etm: Require full global header in auxtrace_info size check", " - perf cs-etm: Bounds-check CPU in cs_etm__get_queue()", " - perf bpf: Validate array presence before casting BPF prog info pointers", " - perf dso: Set standard errno on decompression failure", " - ASoC: tlv320aic3x: restrict CLKDIV bypass Q values in dual-rate mode", " - drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free", " - drm/amd/display: Fix mem_type change detection for async flips", " - drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm", " - drm/amdgpu: initialize irq.lock spinlock earlier", " - 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", " - ALSA: usb-audio: qcom: reject stream disable with no active interface", " - ALSA: usb-audio: qcom: clear opened when stream enable fails", " - 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()", " - dpaa2-switch: fix VLAN upper check not rejecting bridge join", " - devlink: Fix parent ref leak in devl_rate_node_create()", " - devlink: Fix parent ref leak on tc-bw failure", " - net: airoha: fix foe_check_time allocation size", " - net: macb: add TX stall timeout callback to recover from lost TSTART", " write", " - flow_dissector: check device type before reading ETH_ADDRS", " - selftests: vlan_bridge_binding: Fix flaky operational state check", " - 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: Restore initial state on failed device_rename() in", " cfg802154_switch_netns()", " - ieee802154: Avoid calling WARN_ON() on -ENOMEM in", " cfg802154_switch_netns()", " - ieee802154: Remove WARN_ON() in cfg802154_pernet_exit()", " - ieee802154: fix kernel-infoleak in dgram_recvmsg()", " - mac802154: Prevent overwrite return code in", " mac802154_perform_association()", " - md/raid1: honor REQ_NOWAIT when waiting for behind writes", " - md/raid1: free r1_bio when REQ_NOWAIT is set and read would block on", " retry", " - netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()", " - netfilter: ipset: make sure gc is properly stopped", " - netfilter: nft_payload: reject offsets exceeding 65535 bytes", " - netfilter: nft_meta_bridge: add validate callback for get operations", " - netfilter: nft_flow_offload: zero device address for non-ether case", " - netfilter: nf_reject: skip iphdr options when looking for icmp header", " - netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak", " - mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()", " - irqchip/crossbar: Fix parent domain resource leak", " - alloc_tag: fix use-after-free in /proc/allocinfo after module unload", " - selftests/mm: restore default nr_hugepages value via exit trap in", " charge_reserved_hugetlb.sh", " - selftests/mm: restore default nr_hugepages value via exit trap in", " hugetlb_reparenting_test.sh", " - selftests/mm: fix hugetlb pathname construction in", " hugetlb_reparenting_test.sh", " - selftests/mm: fix cgroup task placement and drop memory.current checks", " in hugetlb_reparenting_test.sh", " - selftests/mm: size tmpfs according to PMD page size in", " split_huge_page_test", " - selftests/mm: free dynamically allocated PMD-sized buffers in", " split_huge_page_test", " - selftest/mm: register existing mapping with userfaultfd in hugetlb-", " mremap", " - selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap", " - selftests/mm: skip uffd-stress test when nr_pages_per_cpu is zero", " - 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", " - net: emac: Fix NULL pointer dereference in emac_probe", " - net/sched: act_ct: fix nf_connlabels leak on two error paths", " - net: airoha: Fix skb->priority underflow in airoha_dev_select_queue()", " - ipv6: ndisc: fix NULL deref in accept_untracked_na()", " - dpaa2-switch: do not accept VLAN uppers while bridged", " - 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", " - bpftool: Fix vmlinux BTF leak in cgroup commands", " - bpf: zero-initialize the fib lookup flow struct", " - bpf: Fix effective prog array index with BPF_F_PREORDER", " - power: sequencing: fix ABBA deadlock in pwrseq_device_unregister()", " - gpiolib: initialize return value in gpiochip_set_multiple()", " - 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()", " - ice: call netif_keep_dst() once when entering switchdev mode", " - rtc: isl1208: Balance enable_irq_wake() with disable_irq_wake() on", " cleanup", " - 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", " - i40e: Fix i40e_debug() to use struct i40e_hw argument", " - rtc: msc313: fix NULL deref in shared IRQ handler at probe", " - ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().", " - eth: bnxt: rename ring_err_stats -> ring_drv_stats", " - eth: bnxt: improve the timing of stats", " - ipv4: fib: Don't ignore error route in local/main tables.", " - md/raid5: use stripe state snapshot in break_stripe_batch_list()", " - md/raid5: avoid R5_Overlap races while breaking stripe batches", " - 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", " - gpio: davinci: fix IRQ domain leak on devm_kzalloc failure", " - 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: do not acquire dev->tx_global_lock in netdev_watchdog_up()", " - net: dsa: sja1105: round up PTP perout pin duration", " - veth: fix NAPI leak in XDP enable error path", " - net: usb: lan78xx: restore VLAN and hash filters after link up", " - 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", " - ipv6: fix state corruption during proxy_ndp sysctl restart", " - ipv6: fix missing notification for ignore_routes_with_linkdown", " - eth: fbnic: fix ordering of heartbeat vs ownership", " - thermal: testing: zone: Flush work items during cleanup", " - ACPI: processor_idle: Mark LPI enter functions as __cpuidle", " - 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: dsa: realtek: fix memory leak in rtl8366rb_setup_led()", " - net: phy: realtek: Clear MDIO_AN_10GBT_CTRL_ADV10G bit", " - octeontx2-af: Validate NIX maximum LFs correctly", " - 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", " - LoongArch: Move struct kimage forward declaration before use", " - LoongArch: BPF: Fix outdated tail call comments", " - LoongArch: BPF: Fix off-by-one error in tail call", " - ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count", " - net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync", " - dt-bindings: net: renesas,ether: Drop example \"ethernet-phy-", " ieee802.3-c22\" fallback", " - selftests: tls: size splice_short pipe by page size", " - 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", " - ALSA: FCP: Fix NULL pointer dereference in interface lookup", " - tracing: probes: fix typo in a log message", " - spi: sh-msiof: abort transfers when reset times out", " - ACPI: RIMT: Only defer the IOMMU configuration in init stage", " - riscv: Fix 32-bit call_on_irq_stack() frame pointer ABI", " - gpio: mvebu: fail probe if gpiochip registration fails", " - gpio: htc-egpio: use managed gpiochip registration", " - net: pse-pd: scope pse_control regulator handle to kref lifetime", " - seg6: validate SRH length before reading fixed fields", " - qede: fix out-of-bounds check for cqe->len_list[]", " - sctp: fix SCTP_RESET_STREAMS stream list length limit", " - MIPS: DEC: Ensure RTC platform device deregistration upon failure", " - MIPS: mm: Add check for highmem before removing memory block", " - ASoC: codecs: lpass-va-macro: Fix LPASS Codec Version for SC7280", " - hwmon: adm1275: Prevent reading uninitialized stack", " - hwmon: (pmbus) Fix passing events to regulator core", " - hwmon: (aspeed-g6-pwm-tach) Guard fan RPM calculation against divide-by-", " zero", " - ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump", " - usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()", " - net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy", " - net: libwx: fix VMDQ mask for 1-queue mode", " - 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", " - drm/panthor: Fix potential invalid pointer deref in", " group_process_tiler_oom()", " - drm/panthor: Don't overrule pending immediate ticks in", " sched_resume_tick()", " - drm/panthor: Fix a leak when a group is evicted before the tiler OOM is", " serviced", " - drm/panthor: Interrupt group start/resumption if group_bind_locked()", " fails", " - tracing/eprobes: Allow use of BTF names to dereference pointers", " - tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg", " - tracing/events: Fix to check the simple_tsk_fn creation", " - tracing: eprobe: read the complete FILTER_PTR_STRING pointer", " - tracing/fprobe: Fix NULL pointer dereference in fprobe_fgraph_entry()", " - tracing/probes: Make the $ prefix mandatory for comm access", " - irqchip/gic-v3-its: Fix OF node reference leak", " - irqchip/ts4800: Fix missing chained handler cleanup on remove", " - sctp: fix addr_wq_timer race in sctp_free_addr_wq()", " - virtio_net: disable cb when NAPI is busy-polled", " - cxgb4: Fix decode strings dump for T6 adapters", " - selftests: drv-net: tso: don't touch dangerous feature bits", " - 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: dualpi2: clear stale classification on filter miss", " - 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: Fix double netfs initialisation in afs_root_iget()", " - afs: use kvfree() to free memory allocated by kvcalloc()", " - afs: Remove erroneous seq |= 1 in volume lookup loop", " - afs: Fix bulk lookup malfunction due to change in dir_emit() API", " - afs: Fix misplaced inc of net->cells_outstanding", " - afs: Fix reinitialisation of the inode, in particular ->lock_work", " - afs: Fix callback service message parsers to pass through -EAGAIN", " - afs: Fix missing NULL pointer check in afs_break_some_callbacks()", " - afs: Fix vllist leak", " - afs: Fix lack of locking around modifications of net->cells_dyn_ino", " - afs: Fix premature cell exposure through /afs", " - 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", " - ovl: fix comment about locking order", " - iomap: guard io_size EOF trim against concurrent truncate underflow", " - netfs: Fix writethrough to use collection offload", " - netfs: Fix writeback error handling", " - netfs: Fix folio state after ENOMEM whilst under writeback iteration", " - drm/xe/pt: Fix NULL pointer dereference in xe_pt_zap_ptes_entry()", " - drm/xe/userptr: Hold notifier_lock for write on inject test path", " - drm/xe/hw_engine: Fix double-free of managed BO in error path", " - drm/xe/pf: Don't attempt to process FAST_REQ or EVENT relays", " - x86/uprobes: Keep shadow stack in sync for emulated CALLs", " - uprobes/x86: Use proper mm_struct in __in_uprobe_trampoline", " - cifs: Fix missing credit release on failure in cifs_issue_read()", " - ata: sata_gemini: unwind clocks on IDE pinctrl errors", " - ata: libata-scsi: limit simulated SCSI command copy to response length", " - 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: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()", " - HID: bpf: Fix hid_bpf_get_data() range check", " - selftests/hid: Load only requested struct_ops maps", " - selftests/hid: Cover hid_bpf_get_data() size overflow", " - arm64/sysreg: Fix BWE field encoding in ID_AA64DFR2_EL1", " - net: usb: net1080: validate packet_len before pad-byte access in", " rx_fixup", " - netfilter: xt_u32: reject invalid shift counts", " - netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()", " - netfilter: nft_set_rbtree: get command skips end element with open", " interval", " - netfilter: xt_connmark: reject invalid shift parameters", " - net/mlx5: LAG, MPESW, Fix missing complete() on devcom error", " - net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation", " - net/mlx5e: Fix HV VHCA stats agent registration race", " - net/mlx5e: Fix publication race for priv->channel_stats[]", " - net: microchip: vcap: fix races on the shared Super VCAP block", " - net: qualcomm: rmnet: validate MAP frame length before ingress parsing", " - net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload", " - 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: sco: Fix a race condition in sco_sock_timeout()", " - Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length", " - Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()", " - Bluetooth: L2CAP: fix tx ident leak for commands without a response", " - ring-buffer: Fix event length with forced 8-byte alignment", " - accel/amdxdna: Use unsigned long for nr_pages in amdxdna_hmm_register()", " - net/tls: Consume empty data records in tls_sw_read_sock()", " - net: usb: lan78xx: disable VLAN filter in promiscuous mode", " - gpio: dwapb: reduce allocation to single kzalloc", " - gpio: dwapb: Defer clock gating until noirq", " - tracing: Make tracepoint_printk static as not exported", " - accel/amdxdna: Fix potential amdxdna_umap lifetime race", " - drm/v3d: Reject invalid indirect BO handle in indirect CSD setup", " - net: mdio: select REGMAP_MMIO instead of depending on it", " - net/sched: cake: reject overhead values that underflow length", " - octeontx2-pf: check DMAC extraction support before filtering", " - perf/x86/amd/core: Avoid enabling BRS from the SVM reload path", " - gpio: mvebu: free generic chips on unbind", " - ipv4: igmp: annotate data-races around im->users", " - ipv4: igmp: annotate data-races around timer-related fields", " - ipv4: igmp: Fix potential memory leaks in igmp_mod_timer() and", " igmp_stop_timer()", " - ipvs: pass parsed transport offset to state handlers", " - ipvs: use parsed transport offset in TCP state lookup", " - s390/zcrypt: Remove the empty file", " - SUNRPC: release lower rpc_clnt if killed waiting for XPRT_LOCKED", " - 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", " - drm/xe: remove duplicate include", " - smb: client: fix overflow in passthrough ioctl bounds check", " - idpf: add padding to PTP virtchnl structures", " - 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", " - octeontx2-pf: clear stale mailbox IRQ state before request_irq()", " - octeontx2-vf: clear stale mailbox IRQ state before request_irq()", " - arm64: fpsimd: Fix type mismatch in sve_{save,load}_state()", " - arm64: dts: s32g3: Fix SWT8 watchdog address", " - ARM: dts: imx6ul-var-som: fix warning for non-existent dc-supply", " property", " - arm64: dts: qcom: sdm630: describe adsp_mem region properly", " - arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Ringneck", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix ADC sampling times", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move divergent mecio1 ADC", " channels to board files", " - arm64: dts: ti: k3-am62a7-sk: Add bootph-all tag to vqmmc", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Enable internal ADC reference", " - arm64: dts: imx8ulp-evk: Correct Type-C int GPIO flags", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix GPIO names typo", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move gpio-line-names to board", " files", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix expander gpio line typo", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move expander gpio-line-names to", " board files", " - LoongArch: KVM: Validate irqchip index in irqfd routing", " - 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()", " - powerpc/pseries/Kconfig: Enable CONFIG_VPA_PMU to be used with KVM", " - KVM: s390: pci: Fix GISC refcount leak on AIF enable failure", " - KVM: s390: pci: Fix handling of AIF enable without AISB", " - KVM: SEV: Do not allow intra-host migration/mirroring of SNP VMs", " - KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs", " - KVM: x86: Nullify irqfd->producer if updating IRTE for bypass fails", " - KVM: nVMX: Put vmcs12 pages if nested VM-Enter fails due to invalid", " guest state", " - KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers", " - KVM: arm64: nv: Drop bogus WARN for write to ZCR_EL2", " - KVM: arm64: nv: Write ESR_EL2 for injected nested SError exceptions", " - KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()", " - 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: efifb: fix memory leak in efifb_probe()", " - 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: Check runtime resume during probe", " - ASoC: mediatek: mt8192: Release reserved memory on cleanup", " - ASoC: mediatek: mt8183: Check runtime resume during probe", " - 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: nft_set_pipapo: don't leak bad clone into future transaction", " - 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", " - selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()", " - selinux: fix incorrect execmem checks on overlayfs", " - 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/brs: Fix kernel address leakage", " - perf/x86/amd/lbr: Fix kernel address leakage", " - cpufreq: schedutil: Fix uncleared need_freq_update on the .adjust_perf()", " path", " - cpufreq: intel_pstate: Set non-turbo capacity to HWP_GUARANTEED_PERF()", " - 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: retrieve ethhdr after potential skb realloc on RX", " - 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: ensure minimal ethernet header on TX", " - 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: clean untagged VLAN on netdev registration failure", " - batman-adv: frag: fix primary_if leak on failed linearization", " - batman-adv: mcast: avoid OOB read of num_dests header", " - 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", " - lockd: Plug nlm_file leak when nlm_do_fopen() fails", " - lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure", " - 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()", " - mm/mm_init: fix pageblock migratetype for ZONE_DEVICE compound pages", " - power: supply: cpcap-battery: Fix missing nvmem_device_put() causing", " reference leak", " - power: supply: max17042: fix OF node reference imbalance", " - mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch", " - mm/memory_hotplug: fix incorrect altmap passing in error path", " - 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: bound NTFS_DE view.data_off in", " UpdateRecordData{Root,Allocation}", " - ntfs3: cap RESTART_TABLE free-chain walker at rt->used", " - ntfs3: fix out-of-bounds read in decompress_lznt", " - landlock: Fix LANDLOCK_SCOPE_SIGNAL bypass on the SIGIO path", " - power: supply: charger-manager: fix refcount leak in is_full_charged()", " - selftests/landlock: Test SCOPE_SIGNAL on the SIGIO/fowner pgid path", " - 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", " - 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()", " - proc: only bump parent nlink when registering directories", " - fs/proc: fix KPF_KSM reported for all anonymous pages", " - powerpc/dt_cpu_ftrs: Set CPU_FTR_P11_PVR for Power11 and later", " processors", " - mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE", " - kcov: use WRITE_ONCE() for selftest mode stores", " - mtd: slram: remove failed entries from the device list", " - 9p: skip nlink update in cacheless mode to fix WARN_ON", " - power: supply: bq257xx: Fix VSYSMIN clamping logic", " - scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()", " - scsi: sas: Skip opt_sectors when DMA reports no real optimization hint", " - openrisc: Add full instruction cache invalidate functions", " - 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: fix UBSAN array-index-out-of-bounds in ocfs2_sum_rightmost_rec", " - 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: host: pci_generic: Fix the physical function check", " - 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()", " - s390/pkey: Check length in PKEY_VERIFYPROTK ioctl", " - s390/pkey: Check length in pkey_pckmo handler implementation", " - mtd: spi-nor: swp: Improve locking user experience", " - mtd: spi-nor: spansion: use die erase for multi-die devices only", " - mtd: rawnand: Pause continuous reads at block boundaries", " - openrisc: Fix jump_label smp syncing", " - mtd: maps: vmu-flash: fix NULL pointer dereference in initialization", " - taskstats: retain dead thread stats in TGID queries", " - irqchip/crossbar: Use correct index in crossbar_domain_free()", " - tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()", " - tpm: tpm2-sessions: wait for async KPP completion in tpm_buf_append_salt", " - sunrpc: fix uninitialized xprt_create_args structure", " - dmaengine: tegra: Fix burst size calculation", " - dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and", " ABORT_INT_MASK", " - platform/x86: dell-laptop: fix missing cleanups in init error path", " - platform/x86: ISST: Restore SST-PP control to all domains", " - 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", " - platform/x86/amd/pmc: Don't log during intermediate wakeups", " - pkey: Move keytype check from pkey api to handler", " - 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", " - hwmon: (max6697) add missing 'select REGMAP_I2C' to Kconfig", " - i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)", " - i2c: imx: fix locked bus on SMBus block-read of 0 (IRQ)", " - i2c: mediatek: fix WRRD for SoCs without auto_restart option", " - i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()", " - i2c: spacemit: fix spurious IRQ handling returning IRQ_HANDLED", " - ice: fix ice_init_link() error return preventing probe", " - tcp: Decrement tcp_md5_needed static branch", " - ufs: core: tracing: Do not dereference pointers in TP_printk()", " - xen/gntdev: fix error handling in ioctl", " - xfrm: use compat translator only for u64 alignment mismatch", " - 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()", " - NFS: Charge unstable writes by request size, not folio size", " - nvme-apple: Prevent shared tags across queues on Apple A11", " - nvmet: fix refcount leak in nvmet_sq_create()", " - netdev-genl: report NAPI thread PID in the caller's pid namespace", " - can: esd_usb: kill anchored URBs before freeing netdevs", " - can: isotp: use unconditional synchronize_rcu() in isotp_release()", " - can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER", " - can: isotp: serialize TX state transitions under so->rx_lock", " - 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: Reset register bounds before narrowing retval range in", " check_mem_access()", " - bpf,fork: wipe ->bpf_storage before bailouts that access it", " - bpf: Add missing access_ok call to copy_user_syms", " - block: remove redundant GD_NEED_PART_SCAN in add_disk_final()", " - block: fix race in blk_time_get_ns() returning 0", " - block: fix IORING_URING_CMD_REISSUE flags check in blkdev_uring_cmd", " - 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-pcache: reject option groups without values", " - 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: fix leaking uninitialized kernel memory", " - dm-integrity: fix a bug if the bio is out of limits", " - dm-integrity: don't increment hash_offset twice", " - dm-verity: avoid double increment of &use_bh_wq_enabled", " - dm-verity: fix a possible NULL pointer dereference", " - dm-verity: increase sprintf buffer size", " - dm-verity: make error counter atomic", " - dma-fence: Make dma_fence_dedup_array() robust against 0-count input", " - accel/amdxdna: Fix use-after-free in amdxdna_gem_dmabuf_mmap()", " - accel/ivpu: Reject firmware log with size smaller than header", " - 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: 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 - only expose sysfs attributes on control interface", " - 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 firmware leak in async update", " - 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", " - tracing/user_events: Fix use-after-free in user_event_mm_dup()", " - wifi: libertas_tf: fix use-after-free in lbtf_free_adapter()", " - posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu()", " - selftests/ftrace: Drop invalid top-level local in test_ownership", " - cpu: hotplug: Preserve per instance callback errors", " - cpu: hotplug: Bound hotplug states sysfs output", " - gpio: mt7621: more robust management of IRQ domain teardown", " - gpio: tegra: do not call pinctrl for GPIO direction", " - gpio: mt7621: be sure IRQ domain is created before exposing GPIO chips", " - gpio-f7188x: Add support for NCT6126D version B", " - gpio: mt7621: avoid corruption of shared interrupt trigger state", " - gpios: palmas: add .get_direction() op", " - net: sit: require CAP_NET_ADMIN in the device netns for changelink", " - net: ethernet: ti: icssg: guard PA stat lookups", " - 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", " - selftests: net: fix file owner for broadcast_ether_dst test", " - 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", " - net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for", " changelink", " - octeontx2-af: Free BPID bitmap on setup failure", " - 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", " - platform/x86/amd/pmc: Avoid logging \"(null)\" for DMI values", " - net/sched: sch_teql: move rcu_read_lock()/spin_lock() from _bh variants", " - drm/xe/userptr: Stub notifier_lock helpers when DRM_GPUSVM=n", " - pwm: rzg2l-gpt: Fix period_ticks type from u32 to u64", " - LoongArch: Fix nr passing in set_direct_map_valid_noflush()", " - LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()", " - ipmi: Fix user refcount underflow in event delivery", " - ipmi: fix refcount leak in i_ipmi_request()", " - bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()", " - rtc: renesas-rtca3: Fix PIE clear polling condition in alarm setup error", " path", " - 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", " - fhandle: reject detached mounts in capable_wrt_mount()", " - hwmon: (max1619) add missing 'select REGMAP' to Kconfig", " - tracing/probes: Fix double addition of offset for @+FOFFSET", " - net/mlx5: HWS, fix matcher leak on resize target setup failure", " - 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", " - mm/compaction: handle free_pages_prepare() properly in compaction_free()", " - irqchip/irq-riscv-imsic-early: Fix fwnode leak on state setup failure", " - s390/monwriter: Reject buffer reuse with different data length", " - mac802154: remove interfaces with RCU list deletion", " - octeontx2-pf: fix SQB pointer leak on init failure", " - selftests: net: make busywait timeout clock portable", " - llc: fix SAP refcount leak in llc_ui_autobind()", " - ipvs: use parsed transport offset in SCTP state lookup", " - macsec: don't read an unset MAC header in macsec_encrypt()", " - dibs: loopback: validate offset and size in move_data()", " - net: macb: drop in-flight Tx SKBs on close", " - arm64: smp: Fix hot-unplug tearing by forcing unregistration", " - cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()", " - fs/resctrl: Free mon_data structures on rdt_get_tree() failure", " - fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list", " - ata: libata-core: Skip HPA resize for locked drives", " - ata: libata-core: Allow capacity transition to zero for locked drives", " - riscv: Prevent NULL pointer dereference in machine_kexec_prepare()", " - tracing/osnoise: Call synchronize_rcu() when unregistering", " - s390/diag: Add missing array_index_nospec() call to", " memtop_get_page_count()", " - s390/mm: Fix type mismatch in get_align_mask().", " - selftests/rseq: Fix a building error for riscv arch", " - 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", " - selftests/landlock: Skip scoped_signal subtest with MSG_OOB if not", " available", " - selftests/landlock: Fix screwed up pointers in the scoped_signal_test", " - mmc: sdhci-esdhc-imx: restore pinctrl before restoring ios timing on", " resume", " - powerpc/pseries: fix memory leak on krealloc failure in papr_init", " - net/mlx5: free mlx5_st_idx_data on final dealloc", " - wifi: rt2x00: avoid full teardown before work setup in probe", " - wifi: mwifiex: fix roaming to different channel in host_mlme mode", " - wifi: mac80211: fix memory leak in ieee80211_register_hw()", " - wifi: brcmfmac: cyw: fix heap overflow on a short auth frame", " - riscv: vdso: Do not use LTO for the vDSO", " - 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", " - reset: sunxi: fix memory region leak on ioremap failure", " - powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()", " - wifi: cfg80211: validate EHT MLE before MLD ID read", " - wifi: ieee80211: validate MLE common info length", " - 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", " - mmc: block: fix RPMB device unregister ordering", " - mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe()", " method", " - mmc: sdhci-esdhc-imx: remove unnecessary mmc_card_wake_sdio_irq check", " for tuning save/restore", " - mmc: sdhci-esdhc-imx: restore DLL override for DDR modes on resume", " - mmc: sdhci-esdhc-imx: fix esdhc_change_pinstate() to allow default state", " restore", " - mmc: sdhci-esdhc-imx: disable irq during suspend to fix unhandled", " interrupt", " - mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspend", " - mmc: sdhci-esdhc-imx: make non-fatal errors non-blocking in suspend", " - mmc: sdhci-esdhc-imx: fix resume error handling", " - crypto: xilinx-trng - Remove crypto_rng interface", " - 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: hid-sensor-rotation: Fix stale or zero output when reading raw", " values", " - ALSA: scarlett2: Allow selecting config_set by firmware version", " - ALSA: scarlett2: Update offsets for 2i2 Gen 4 firmware 2417", " - firmware_loader: Add cancel helper for async requests", " - ALSA: hda/tas2781: Cancel async firmware request at unbind", " - binder: Use LIST_HEAD() to initialize on stack list head", " - binder: cache secctx size before release zeroes it", " - staging: rtl8723bs: fix spaces around binary operators", " - Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister", " - Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()", " - proc: rename proc_setattr to proc_nochmod_setattr", " - usb: dwc3: Support USB3340x ULPI PHY high-speed negotiation.", " - usb: dwc3: fix dwc3_readl() and dwc3_writel() calls in dwc3_ulpi_setup()", " - usb: atm: ueagle-atm: use dev_dbg() for 'device found' message", " - usb: atm: ueagle-atm: remove function entry/exit debug messages", " - usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()", " - btrfs: remove folio parameter from ordered io related functions", " - KVM: arm64: Ensure level is always initialized when relaxing perms", " - KVM: arm64: Fix propagation of TLBI level in", " kvm_pgtable_stage2_relax_perms()", " - mm/damon/core: always put unsuccessfully committed target pids", " - mm/damon/core: trace esz at first setup", " - samples/damon/mtier: fail early if address range parameters are invalid", " - perf callchain: Handle multiple address spaces", " - soc: fsl: qe_ports_ic: Add missing cleanup on device removal", " - drm/rockchip: inno-hdmi: Switch to drmm_kzalloc()", " - accel/amdxdna: Create shared functions for AIE2 and AIE4", " - Revert \"UBUNTU: SAUCE: accel/amdxdna: Support sensors for column", " utilization\"", " - accel/amdxdna: Support sensors for column utilization", " - accel/amdxdna: Adjust size for copy_to_user()", " - accel/amdxdna: Handle DETACH_DEBUG_BO through config_debug_bo path", " - accel/amdxdna: Fix order of canceled mailbox messages", " - accel/amdxdna: Guard management mailbox channel cleanup against NULL", " pointer", " - drm/amdkfd: fix redundant MQD iterations in GFX v12.1", " - wifi: ath12k: Fix invalid IRQ requests during AHB probe", " - libbpf: Fix deduplication of typedef with base definitions", " - spi: atcspi200: Use helper function devm_clk_get_enabled()", " - spi: atcspi200: fix use-after-free when driver unbind", " - arm64: dts: rockchip: Fix vdec register blocks order on RK3576", " - arm64: dts: rockchip: Update vdec register blocks order on RK3588", " - dt-bindings: net: bluetooth: qualcomm: Fix WCN6855 regulator names", " - x86/bug: Add printf() validation to HAVE_ARCH_BUG_FORMAT_ARGS WARNs", " - arm64: dts: qcom: milos: Reduce rmtfs_mem size to 2.5MiB", " - arm64: dts: qcom: sdm845-oneplus: Drop address from framebuffer node", " - arm64: dts: qcom: sdm845-shift-axolotl: Correct touchscreen sleep state", " - soc: xilinx: Fix race condition in event registration", " - wifi: ath11k: cancel SSR work items during PCI shutdown", " - ixgbe: fix unaligned u32 access in ixgbe_update_flash_X550()", " - objtool/klp: Fix is_uncorrelated_static_local() for Clang", " - objtool/klp: Fix .data..once static local non-correlation", " - objtool/klp: Fix create_fake_symbols() skipping entsize-based sections", " - objtool/klp: Fix handling of zero-length .altinstr_replacement sections", " - objtool/klp: Fix cloning of zero-length section symbols", " - objtool/klp: Fix extraction of text annotations for alternatives", " - objtool/klp: Fix relocation conversion failures for R_X86_64_NONE", " - objtool/klp: Use sym->demangled_name for symbol_name hash", " - objtool/klp: Match symbols based on demangled_name for global variables", " - objtool: Replace iterator callback with for_each_sym_by_mangled_name()", " - objtool: Fix reloc hash collision in find_reloc_by_dest_range()", " - klp-build: Fix hang on out-of-date .config", " - klp-build: Fix checksum comparison for changed offsets", " - riscv: dts: microchip: gpio controllers on mpfs need 2 interrupt cells", " - riscv: dts: microchip: remove gpio hogs from beaglev-fire", " - wifi: cfg80211: restrict LMR feedback check to TB and non-TB ranging", " - drm/panel: Clean up SOFEF00 config dependencies", " - drm/panel: Clean up S6E3FC2X01 config dependencies", " - arm64: dts: marvell: samsung-coreprimevelte: Increase touchscreen", " voltage", " - arm64: dts: imx8mn-vhip4-evalboard-v1: Correct interrupt flags", " - arm64: dts: imx8mn-vhip4-evalboard-v2: Correct interrupt flags", " - crypto: ccp - Check for page allocation failure correctly in TIO", " - crypto: ccp - Initialize data during __sev_snp_init_locked()", " - accel/amdxdna: Fix clflush buffer size", " - ntb: Store original DMA address for future release", " - ntb: Use consistent DMA attributes when freeing DMA mappings", " - riscv: dts: spacemit: k3: add clock tree", " - dts: riscv: spacemit: correct 32k clock frequency", " - arm64: dts: qcom: sdm660: set cdsp compute-cbs' regs properly", " - arm64: dts: qcom: sdm630: set adsp compute-cbs' regs properly", " - arm64: dts: qcom: lemans: Move PCIe devices into soc node", " - sockptr: fix usize check in copy_struct_from_sockptr() for user pointers", " - arm64: dts: mediatek: mt7988a-bpi-r4pro: rework pcie gpio-hog handling", " - rhashtable: give each instance its own lockdep class", " - thermal: hwmon: Register a hwmon device for each thermal zone", " - crypto: ccp/sev-dev-tsm - bail out early when pdev->bus is NULL", " - crypto: safexcel - Fix potential memory leak in safexcel_pci_probe()", " - net/sched: add qdisc_qlen_inc() and qdisc_qlen_dec()", " - net/sched: sch_dualpi2: annotate data-races in dualpi2_dump_stats()", " - tools/rtla: Fix --dump-tasks usage in timerlat", " - rtla: Stop the record trace on interrupt", " - dm: limit target bio polling to one shot", " - selftests/bpf: Override EXTRA_LDFLAGS for static builds", " - sched/fair: Update util_est after updating util_avg during dequeue", " - hfs: fix incorrect inode ID assignment in hfs_new_inode()", " - vfio: selftests: Fix out-of-tree build with make O=", " - vfio: selftests: Allow builds when ARCH=x86", " - vfio/xe: avoid duplicate reset in xe_vfio_pci_reset_done", " - arm64: dts: qcom: kaanapali: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sdm845-xiaomi-beryllium: Correct IPA FW path", " - ASoC: mediatek: mt8189: Fix probe resource cleanup", " - drm/msm/mdss: correct UBWC programming sequences", " - tools/nolibc: stackprotector: Avoid stalling program startup if crng is", " not init yet", " - ASoC: dapm: Fix widget lookup with prefixed names across DAPM contexts", " - ACPI: PAD: Fix teardown ordering in acpi_pad_remove()", " - wifi: ath12k: fix error unwind on arch_init() failure in PCI probe", " - cpufreq: governor: Fix data races on per-CPU idle/nice baselines", " - cpufreq: governor: Fix stale prev_cpu_nice spike when enabling", " ignore_nice_load", " - dt-bindings: vendor-prefixes: Add Verbatim Corporation", " - drm/tegra: fbdev: Do not assign to struct drm_fb_helper.info", " - rust: devres: add 'static bound to Devres", " - lib/base64: validate before writing in decode tail path", " - rust: uaccess: use INLINE_COPY_TO_USER to guard copy_to_user()", " - uaccess: unify inline vs outline copy_{from,to}_user() selection", " - uaccess: minimize INLINE_COPY_USER-related ifdefery", " - crypto: ccp/tsm - Enable the root port after the endpoint", " - firmware: samsung: acpm: Add devm_acpm_get_by_phandle helper", " - firmware: samsung: acpm: remove compile-testing stubs", " - drm/msm/a8xx: Make a8xx_recover IFPC safe", " - drm/msm/a8xx: Fix RSCC offset", " - EDAC/igen6: Fix memory topology parsing for Panther Lake-H SoCs", " - arm: dts: bcm2711: Fix typo in gpio-line-names", " - arm64: dts: renesas: r8a78000: Fix GIC-720AE View 1 Redistributor", " description", " - arm64: dts: renesas: ironhide: Describe all reserved memory", " - md: replace wait loop with wait_event() in md_handle_request()", " - md/raid1,raid10: fix deadlock in read error recovery path", " - md/raid1,raid10: fix error-path detection with md_cloned_bio()", " - md/raid1,raid10: fix bio accounting for split md cloned bios", " - liveupdate: Use refcount_t for FLB reference counts", " - liveupdate: Reference count incoming FLB data", " - liveupdate: skip serialization for context-preserving kexec", " - liveupdate: fix TOCTOU race in luo_session_retrieve()", " - liveupdate: block session mutations during reboot", " - spi: imx: replace dmaengine_terminate_all() with", " dmaengine_terminate_sync()", " - wifi: ath12k: fix memory leak in ath12k_wifi7_dp_rx_h_verify_tkip_mic()", " - wifi: ath12k: fix inconsistent arvif state in vdev_create error paths", " - ACPI: button: Fix lid_device value leak past driver removal", " - drm/amd/pm: Add empty string validation to sysfs store functions", " - accel/amdxdna: Return errors for failed debug BO commands", " - mm: preserve PG_dropbehind flag during folio split", " - perf/x86/intel/uncore: Fix PCI device refcount leak in UPI discovery", " - wifi: wlcore: enable the right set of ciphers", " - cxl/test: Fix __fortify_panic", " - bpf: Take mmap_lock in zap_pages()", " - ocfs2: fix out-of-bounds write in ocfs2_remove_refcount_extent", " - cxl/pci: Fix the incorrect check of pci_read_config_word() return", " - cxl/pci: Convert PCIBIOS errors to errno on DVSEC config accesses", " - netfilter: cttimeout: detach dataplane timeout policy and repurpose", " refcount", " - arm64: dts: imx94: fix DDR PMU interrupt number", " - arm64: dts: freescale: fsl-ls1028a-tqmls1028a-mbls1028a: switch mmc", " aliases", " - selftests/bpf: Fix flaky file_reader test", " - riscv: alternative: Use IS_ENABLED() over ifdeffery for", " apply_vdso_alternatives()", " - riscv: alternative: Pass vDSO start as parameter to", " apply_vdso_alternatives()", " - riscv: alternative: Also patch the CFI vDSO", " - bpf: Verifier support for sleepable tracepoint programs", " - bpf: Reject sleepable BPF_LSM_CGROUP programs at load time", " - netfilter: flowtable: avoid num_encaps underflow on bridge VLAN untag", " - filelock: fix break_lease() stub signature for CONFIG_FILE_LOCKING=n", " - wifi: mac80211: bound S1G TIM PVB walk to the TIM element", " - ACPI: processor: Add cpuidle driver check in", " acpi_processor_register_idle_driver()", " - RDMA/nldev: Fix locking when accessing mr->pd", " - scsi: ufs: core: Handle PM commands timeout before SCSI EH", " - iommufd: Destroy the pages content after detaching from dmabuf", " - lib/test_hmm: fix memory leak in dmirror_migrate_to_system()", " - rust: kbuild: show the right `quiet_cmd_rustc_procmacrolibrary`", " - remoteproc: qcom_q6v5_wcss: drop redundant wcss_q6_bcr_reset", " - wifi: mt76: mt7996: remove redundant pdev->bus check in probe", " - wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bits", " - memory: tegra186-emc: stop borrowing MC aggregate hook for EMC", " - PM: QoS: Fix misc device registration unwind", " - btrfs: lzo: reject compressed segment that overflows the compressed", " input", " - ixgbe: do not configure xps for XDP queues", " - bpf: Cancel special fields on map value recycle", " - clocksource: move NXP timer selection to drivers/clocksource", " - [Config] Allow certain NXP timer selections for arm64", " - vduse: fix compat handling for VDUSE_IOTLB_GET_FD/VDUSE_VQ_GET_INFO", " - iomap: pass the correct len to fserror_report_io in __iomap_write_begin", " - ASoC: cs35l56: Prevent double-free of debugfs", " - ASoC: cs35l56: Cleanup if component_probe fails", " - hwmon: (gpd-fan): drop global driver data and use per-device allocation", " - hwmon: (gpd-fan): Initialize EC before registering hwmon device", " - hwmon: (gpd-fan): fix race condition between device removal and sysfs", " access", " - ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT", " - cxl/test: Verify cmd->size_in before accessing payload", " - m68k: mcf5441x: fix clocks numbering", " - pinctrl: airoha: an7583: add missed gpio32 pin group", " - pinctrl: airoha: an7583: fix misprint in gpio19 pinconf", " - pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin", " function", " - pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin", " function", " - pinctrl: airoha: fix pwm pin function for an7581 and an7583", " - pinctrl: airoha: an7583: fix gpio21 pin group", " - pinctrl: airoha: an7583: add missed gpio22 pin group", " - pinctrl: airoha: an7583: fix phy1_led1 pin function", " - pinctrl: airoha: an7583: remove undefined groups from pcm_spi pin", " function", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_setup() for non-", " serdev device", " - Bluetooth: btintel: Replace CNVi id with hardware variant", " - Bluetooth: btintel: Add DSBR support for ScP2 onwards", " - Bluetooth: btintel_pcie: Load IOSF debug regs by controller variant", " - ASoC: cs35l56: Fix wrong error test on simple_write_to_buffer()", " - ASoC: SOF: Intel: select SND_SOC_SDW_UTILS=y from", " SND_SOC_SOF_HDA_GENERIC=y", " - ASoC: meson: aiu: Validate written enum values", " - ASoC: topology: Check PCM and DAI name strings before use", " - ipv4: fib: Don't dump dying fib_info in fib_leaf_notify().", " - iommu/dma-iommu: Fix wrong scatterlist length assignment in P2PDMA path", " - iommufd: Clarify IOAS_MAP_FILE dma-buf support", " - cxl/region: Fill first free targets[] slot during auto-discovery", " - vfio: selftests: Ensure libvfio output dirs are always created", " - cxl/region: Block region delete during region creation", " - cxl/region: Resolve region deletion races", " - cxl/memdev: Pin parents for entire memdev lifetime", " - net: airoha: Fix error handling in airoha_ppe_flush_sram_entries()", " - netfilter: nft_fwd_netdev: use recursion counter in neigh egress path", " - netfilter: nf_dup_netdev: add nf_dev_xmit_recursion*() helpers and use", " them", " - geneve: Fix off-by-one comparing with GRO_LEGACY_MAX_SIZE", " - smb: client: fix conflicting option validation for new mount API", " - btrfs: Drop WQ_PERCPU from ordered_flags in btrfs_init_workqueues()", " - bpf: Guard __get_user acesss with access_ok for uprobe_multi data", " - net: ti: icssg-prueth: Fix AF_XDP fill ring alloc and wakeup condition", " - net: ti: icssg: Use undirected TX tag for native XDP in HSR offload mode", " - net: ti: icssg: Use undirected TX tag for XDP zero copy in HSR offload", " mode", " - RDMA/bnxt_re: Free CQ toggle page after firmware teardown", " - RDMA/bnxt_re: Reject GET_TOGGLE_MEM when toggle page was not allocated", " - RDMA/hns: Fix memory leak of bonding resources", " - mfd: bd72720: Drop BUCK11 ID", " - 9p: Add missing read barrier in virtio zero-copy path", " - perf dwarf-aux: Fix libdw segmentation fault in cu_walk_functions_at", " - perf dwarf-aux: Fix libdw API contract violations", " - perf srcline: Introduce inline_node__clear_frames()", " - perf libdw: Fix libdw API contract violations and memory leaks", " - perf probe-finder: Fix libdw API contract violations", " - perf annotate-data: Fix libdw API contract violations", " - coresight: tmc: Fix overflow when calculating is bigger than 2GiB", " - perf tool: Fix missing schedstat delegates and dont_split_sample_group", " in delegate_tool", " - PCI: intel-gw: Move interrupt enable to own function", " - PCI: intel-gw: Enable clock before PHY init", " - PCI: intel-gw: Add .start_link() callback", " - bus: mhi: ep: Add missing state_lock protection for mhi_state access", " - PCI: dwc: Apply ECRC workaround for DesignWare cores prior to 5.10a", " - PCI: qcom: Set max OPP before DBI access during resume", " - perf pmu-events AMD: Switch l2_itlb_misses to", " bp_l1_tlb_miss_l2_tlb_miss.all", " - perf unwind: Refactor get_entries to allow dynamic libdw/libunwind", " selection", " - coresight: Handle helper enable failure properly", " - mailbox: don't free the channel if the startup callback failed", " - PCI/pwrctrl: Lock device when calling device_is_bound()", " - coresight: platform: defer connection counter increment until alloc", " succeeds", " - platform/x86: classmate-laptop: Address memory leaks on driver removal", " - clk: microchip: mpfs-ccc: fix peripheral driver registration failures", " after oob fix", " - perf sample: Add evsel to struct perf_sample", " - perf event: Fix size of synthesized sample with branch stacks", " - perf inject: Fix itrace branch stack synthesis", " - gpib: cb7210: Fix region leak when request_irq fails", " - timers/migration: Update stale @online doc to @available", " - clk: spacemit: k3: Switch to pll2_d6 as parent for PCIe clock", " - clk: spacemit: k3: Fix PCIe clock register offset", " - fs/ntfs3: fix wrong LCN in run_remove_range() when splitting a run", " - ntfs3: Allocate iomap inline_data using alloc_page", " - perf sample: Add file_offset field to struct perf_sample", " - perf sched: Replace BUG_ON on invalid CPU with graceful skip", " - perf sched: Fix NULL dereference in latency_runtime_event", " - perf sched: Fix comp_cpus heap overflow with cross-machine recordings", " - perf tools: Guard remaining test_bit calls from OOB sample CPU", " - perf sched: Fix thread reference leaks in timehist_get_thread()", " - perf sched: Use is_idle_sample() for idle thread runtime cast guard", " - perf sched: Fix thread reference leak in idle hist processing", " - perf sched: Free callchain nodes in idle thread cleanup", " - docs: memfd_preservation: fix rendering of ABI documentation", " - virtio: add missing kernel-doc for map and vmap members", " - fs/ntfs3: prevent potential lcn remains uninitialized", " - perf tools: NULL bitmap pointers after bitmap_free()", " - perf tools: Use scnprintf() in build_id__snprintf() and hwmon", " read_events()", " - perf data convert json: Fix addr_location leak on time-filtered samples", " - perf tools: Use mkostemp() for O_CLOEXEC on temporary files", " - phy: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put", " in reset", " - sparc: Avoid -Wunused-but-set-parameter in clear_user_page()", " - apparmor: release exe file resources on path failure", " - apparmor: remove unnecessary goto and associated label", " - apparmor: Fix inverted comparison in cache_hold_inc()", " - i3c: mipi-i3c-hci: Fix suspend behavior when bus disable falls back to", " software reset", " - i3c: master: Serialize i3c_set_hotjoin() with the maintenance lock", " - i3c: mipi-i3c-hci: Fix race in i3c_hci_addr_to_dev()", " - perf maps: Add maps__mutate_mapping", " - perf c2c: Free format list entries when releasing c2c hist entries", " - regcache: Do not overwrite error code when finalizing cache after error", " - erofs: call erofs_exit_ishare() before rcu_barrier()", " - perf c2c: Free format list entries when c2c_hists__init() fails", " - perf c2c: Fix hist entry and format list leaks in c2c_he_free()", " - drm/amd/display: Skip PHY SSC reduction on some 8K panels", " - net: ethernet: mtk_eth_soc: fix supported_interface set after", " phylink_create", " - selftests/ftrace: Fix trace_marker_raw test on 64K page kernels", " - octeontx2-af: npc: Log successful MCAM drop-on-non-hit install at debug", " level", " - netconsole: don't drop the last byte of a full-sized message", " - eth: fbnic: take netif_addr_lock_bh() around rx mode address programming", " - arm64: static_call: include asm/insns.h", " - md/raid1: fix writes_pending and barrier reference leaks on write", " failures", " - md/raid10: fix writes_pending leak on write request failures", " - md/raid10: fix writes_pending and barrier reference leaks on discard", " failures", " - netfilter: ipset: Don't use test_bit() in lockless RCU readers in bitmap", " types", " - selftests/mm: fix hugetlb pathname construction in", " charge_reserved_hugetlb.sh", " - selftests/mm: run_vmtests.sh: free memory if available memory is low", " - selftests/mm: move hwpoison setup into run_test() and silence modprobe", " output for memory-failure category", " - selftests/mm: remove hardcoded THP sizing assumptions in hmm tests", " - net: dst_metadata: fix false-positive memcpy overflow in tun_dst_unclone", " - bpf: Fix partial copy of non-linear test_run output", " - bpf: Fix BPF_PROG_ASSOC_STRUCT_OPS last field check", " - erofs: handle 48-bit blocks_hi for compressed inodes", " - ASoC: cs530x: Fix expected MCLK rates for CS5302/4/8", " - PCI: endpoint: pci-epf-vntb: Document legacy MSI doorbell offset", " - PCI: endpoint: pci-epf-vntb: Defer pci_epc_raise_irq() out of atomic", " context", " - PCI: endpoint: pci-epf-vntb: Report 0-based doorbell vector via", " ntb_db_event()", " - e1000e: Reconfigure PLL clock gate timeout and re-enable K1 on Meteor", " Lake", " - bpf: Guard conntrack opts error writes", " - selftests/bpf: Cover small conntrack opts error writes", " - netfilter: nf_conntrack_helper: dynamically allocate struct", " nf_conntrack_helper", " - netfilter: nf_conntrack_pptp: move GRE specific cleanup to GRE tracker", " - netfilter: nf_conntrack_gre: fix gre keymap list corruption", " - netfilter: conntrack: check NULL when retrieving ct extension", " - netfilter: nf_conntrack_expect: use conntrack GC to reap expectations", " - netfilter: nf_conntrack_expect: store master_tuple in expectation", " - netfilter: nf_conntrack_expect: run expectation eviction with no helper", " - netfilter: nft_ct: expectation timeouts are passed in milliseconds", " - netfilter: nf_conntrack_helper: cap maximum number of expectation at", " helper registration", " - cpuidle: Allow exit latency to exceed target residency", " - ASoC: SDCA: Validate written enum value in ge_put_enum_double()", " - ASoC: rt5575: Use __le32 for SPI burst write address", " - PCI: endpoint: pci-epf-vntb: Exclude reserved slots from db_valid_mask", " - net: ti: icssg: Fix XSK zero copy TX during application wakeup", " - net: lwtunnel: Drop skb metadata before LWT encapsulation", " - sctp: fix err_chunk memory leaks in INIT handling", " - net: dsa: mxl862xx: avoid unaligned 16-bit access in api_wrap", " - octeontx2-af: fix CGX debugfs RVU AF PCI reference leaks", " - geneve: gate GRO hint in geneve_gro_complete() on gs->gro_hint", " - geneve: validate inner network offset in geneve_gro_complete()", " - tools: ynl: build archives with $(AR)", " - net: enetc: fix potential divide-by-zero when num_vsi is zero", " - udp_tunnel: Pass struct sock to setup_udp_tunnel_sock().", " - tipc: avoid busy looping in tipc_exit_net()", " - bpf: Mask pseudo pointer values in verifier logs", " - bpf: Fix insn_aux_data leak on verifier err_free_env path", " - hwmon: (pmbus/core) Add support for NVIDIA nvidia195mv mode", " - hwmon: (pmbus/core) honor vrm_version in pmbus_data2reg_vid()", " - gpio: shared-proxy: always serialize with a sleeping mutex", " - drm/panthor: Always use the IRQ-safe variant when acquiring the fence", " lock", " - drm/panthor: Keep the reset work disabled until everything is", " initialized", " - drm/panthor: Fix panthor_pwr_unplug()", " - spi: rzv2h-rspi: Fix DMA transfer error handling for signal interruption", " - xen/pvcalls: bound backend response req_id before indexing rsp[]", " - afs: Remove setting of AS_RELEASE_ALWAYS for symlinks and mountpoints", " - afs: Fix directory inode initialisation order", " - afs: Use scoped_seqlock_read() rather than manually doing seqlock stuff", " - afs: Fix leak of ungot volume", " - iomap: release pages on atomic dio size mismatch", " - cachefiles: Fix double unlock in nomem_d_alloc error path", " - cachefiles: Fix file burial to take lock when unsetting S_KERNEL_FILE", " - drm/imagination: Fix returned size for DRM_IOCTL_PVR_DEV_QUERY", " - iio: dac: mcp47feb02: Fix passing uninitialized vref1_uV for no Vref1", " case", " - net/mlx5: LAG, replace pf array with xarray", " - net/mlx5: LAG, use xa_alloc to manage LAG device indices", " - net/mlx5: Lag: refactor representor reload handling", " - net/mlx5: E-Switch, add representor lifecycle lock", " - net/mlx5: Lag, avoid LAG and representor lock cycles", " - net/mlx5: LAG, factor out shared FDB code into dedicated file", " - net/mlx5: LAG, replace peer count check with direct peer lookup", " - net/mlx5: LAG, prepare for SD device integration", " - net/mlx5: LAG, replace mlx5_get_dev_index with LAG sequence number", " - net/mlx5: LAG, extend shared FDB API with group_id filter", " - net/mlx5: LAG, Fix off-by-one in single-FDB error rollback", " - ksmbd: fix multichannel binding and enforce channel limit", " - smb: client: preserve leading slash for POSIX absolute symlink targets", " - gpio: shared: make the voting mechanism adaptable", " - drm/i915/ltphy: Fix SSC Enablement bit in PORT_CLOCK_CTL", " - Bluetooth: 6lowpan: avoid untracked enable work", " - Bluetooth: btintel_pcie: Support Product level reset", " - [Config] Make BT_INTEL_PCIE depend on ACPI", " - Bluetooth: btintel_pcie: Add support for smart trigger dump", " - Bluetooth: btintel_pcie: Separate coredump work from RX work", " - Bluetooth: btintel_pcie: Refactor FLR to use device_reprobe()", " - Bluetooth: ISO: fix malformed ISO_END/CONT handling", " - accel/amdxdna: Prevent PM resume deadlock in hwctx_sync_debug_bo()", " - accel/amdxdna: Fix VMA access race", " - net: rnpgbe: fix mailbox endianness and remove pointer casts", " - drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE", " - smb: client: fix busy dentry warning on unmount after DIO", " - drm/fb-helper: Only consider active CRTCs for vblank sync", " - ethtool: rss: Fix hfunc and input_xfrm parsing on big endian", " - drm/imagination: make pvr_fw_trace_init_mask_ops static", " - VDUSE: avoid leaking information to userspace", " - ASoC: SOF: ipc4-control: Validate notification payload size", " - arm64: dts: renesas: ironhide: Describe inline ECC carveouts", " - arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers", " - KVM: s390: vsie: Fix allocation of struct vsie_rmap", " - KVM: s390: vsie: Add missing radix_tree_preload() in", " _gaccess_shadow_fault()", " - KVM: s390: Add some useful mask macros", " - KVM: s390: vsie: Fix rmap handling in _do_shadow_crste()", " - KVM: s390: vsie: Fix redundant rmap entries", " - KVM: s390: vsie: Use mmu cache to allocate rmap", " - KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory", " - KVM: TDX: Reject concurrent change to CPUID entry count", " - ASoC: SOF: topology: fix memory leak in snd_sof_load_topology", " - netfilter: nft_fib: reject fib expression on the netdev egress hook", " - netfilter: nf_conntrack_sip: remove net variable shadowing", " - netfilter: nf_conntrack_sip: validate skb_dst() before accessing it", " - gpu/buddy: bail out of try_harder when alignment cannot be honoured", " - backlight: ktd2801: Enable BL_CORE_SUSPENDRESUME", " - cxl: Fix CXL_HEADERLOG_SIZE to match RAS Capability size", " - pinctrl: renesas: rzg2l: Use -ENOTSUPP instead of -EOPNOTSUPP", " - remoteproc: xlnx: Check remote core state", " - mm/sparse-vmemmap: fix vmemmap accounting underflow", " - mm/huge_memory: preserve pmd_swp_uffd_wp on device-private PMD downgrade", " - fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race", " - fs/proc/task_mmu: do not warn on seeing non-migration pmd entry", " - kho: make sure scratch size is always aligned by CMA_MIN_ALIGNMENT_BYTES", " - mtd: maps: vmu-flash: fix fault in unaligned fixup", " - dmaengine: dw-edma-pcie: Reject devices without driver data", " - dmaengine: sh: rz-dmac: Move interrupt request after everything is set", " up", " - platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8D26)", " - platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8E35)", " - spi: imx: reconfigure for PIO when DMA cannot be started", " - ovl: use linked upper dentry in copy-up tmpfile", " - can: bcm: add locking when updating filter and timer values", " - can: bcm: extend bcm_tx_lock usage for data and timer updates", " - can: bcm: fix CAN frame rx/tx statistics", " - can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()", " - can: bcm: fix stale rx/tx ops after device removal", " - can: bcm: track a single source interface for ANYDEV timeout/throttle", " ops", " - can: bcm: validate frame length in bcm_rx_setup() for RTR replies", " - can: bcm: add missing device refcount for CAN filter removal", " - selftests/bpf: Cover negative buffer pointer offsets", " - dm: avoid leaking the caller's thread keyring via the table device file", " - dma-buf: protected fence ops by RCU v8", " - dma-fence: use correct callback in dma_fence_timeline_name()", " - accel/amdxdna: reject command submission on devices without a submit op", " - accel/amdxdna: reject user command submission without a command BO", " - accel/amdxdna: Use caller client for debug BO sync", " - fs/resctrl: Fix use-after-free during unmount", " - mmc: vub300: fix use-after-free on probe failure", " - octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF", " - ksmbd: fix stack buffer overflow in multichannel session-key copy", " - netfilter: nfnetlink_cthelper: cap to maximum number of expectation per", " master", " - netfilter: nfnetlink_cthelper: cap to maximum number of expectation per", " master on updates", " - riscv: vdso: Always declare vdso_start symbols", " - ata: libata-core: Add NOLPM quirk for PNY CS900 1TB SSD", " - ata: libata-core: Reject an invalid concurrent positioning ranges count", " - net: ipa: fix SMEM state handle leaks in SMP2P init", " - amdkfd: properly free secondary context id", " - pmdomain: imx93-blk-ctrl: Extract PHY as shared domain for DSI/CSI", " - pmdomain: mediatek: Fix possible nullptr KP in HWV cleanup/on-check", " - arch/riscv: vdso: remove CFI landing pad from rt_sigreturn", " - reset: imx7: Correct polarity of MIPI CSI resets on i.MX8MQ", " - powerpc/uaccess: correct check for CONFIG_PPC_E500 in", " mask_user_address()", " - wifi: mac80211: validate extension-frame layout before RX", " - xfs: factor out a xfs_zone_mark_free helper", " - xfs: add newly added RTGs to the free pool in growfs", " - liveupdate: validate session type before performing operation", " - posix-timers: Expand timer_[re]arm() callbacks with a boolean return", " value", " - posix-cpu-timers: Prevent UAF caused by non-leader exec() race", " - Revert \"gpib: cb7210: Fix region leak when request_irq fails\"", " - Upstream stable to v6.18.40, v7.1.5", " * Resolute update: upstream stable patchset 2026-08-20 (LP: #2164666) //", " CVE-2023-20585", " - 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", " * [Regression] Laptop fails to power off completely when HDMI is connected", " in kernel 7.0.0-28 (LP: #2163121) // CVE-2026-68364", " - drm/amd/display: fix NULL ptr deref in ISM delayed work", " - drm/amd/display: Fix ISM teardown crash from NULL dc dereference", " - drm/amd/display: Fix ISM dc_lock deadlock during suspend", " * CVE-2026-72064", " - net: mana: Sync page pool RX frags for CPU", " * CVE-2026-72065", " - net: mana: Validate the packet length reported by the NIC", " * CVE-2026-72098", " - dm-verity-fec: replace {MAX,MIN}_RSN with {MIN,MAX}_ROOTS", " - dm-verity: fix buffer overflow in FEC calculation", " * CVE-2026-72248", " - netfilter: flowtable: support IPIP tunnel with direct xmit", " - netfilter: flowtable: use correct direction to set up tunnel route", " * CVE-2026-72249", " - netfilter: flowtable: use dst in this direction when pushing IPIP header", " * CVE-2026-72287", " - KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\"", " checks", " * CVE-2026-72329", " - net/liquidio: drop cached VF pci_dev LUT", " * CVE-2026-72355", " - netfs: Fix barriering when walking subrequest list", " * CVE-2026-72412", " - s390/mm: Fix handling of _PAGE_UNUSED pte bit", " * CVE-2026-72417", " - netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto()", " * CVE-2026-72442", " - netfilter: flowtable: fix and simplify IP6IP6 tunnel handling", " * CVE-2026-72463", " - xfrm: Fix dev use-after-free in xfrm async resumption", " * CVE-2026-72477", " - fs/ntfs3: call _ntfs_bad_inode() when failing to rename", " * CVE-2026-72493", " - net: serialize netif_running() check in enqueue_to_backlog()", " * CVE-2026-72494", " - RDMA/irdma: Replace waitqueue and flag with completion", " * CVE-2026-72496", " - RDMA/bnxt_re: Proper rollback if the ioremap fails", " * CVE-2026-74269", " - bnxt: fix head underflow on XDP head-grow", " * CVE-2026-74350", " - ocfs2: validate fast symlink target during inode read", " * CVE-2026-72495", " - RDMA/bnxt_re: Avoid repeated requests to allocate WC pages", " * CVE-2026-72501", " - RDMA/bnxt_re: Initialize dpi variable to zero", " * CVE-2026-72278", " - KVM: arm64: nv: Re-translate VNCR before injecting abort", " * CVE-2026-68083", " - ksmbd: fix path resolution in ksmbd_vfs_kern_path_create", " * CVE-2026-68457", " - ksmbd: use opener credentials for FSCTL mutations", " * CVE-2026-68476", " - ipvs: reload ip header after head reallocation", " * CVE-2026-68477", " - ipvs: fix more places with wrong ipv6 transport offsets", " * CVE-2026-72014", " - drbd: reject data replies with an out-of-range payload size", " * CVE-2026-72020", " - ipvs: reset full ip_vs_seq structs in ip_vs_conn_new", " * CVE-2026-72033", " - orangefs: keep the readdir entry size 64-bit in fill_from_part()", " * CVE-2026-72041", " - espintcp: use sk_msg_free_partial to fix partial send", " * CVE-2026-72046", " - gve: fix header buffer corruption with header-split and HW-GRO", " * CVE-2026-72069", " - locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()", " * CVE-2026-72083", " - scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE", " * CVE-2026-72084", " - scsi: target: Bound PR-OUT TransportID parsing to the received buffer", " * CVE-2026-72085", " - scsi: xen: scsiback: Free unsubmitted command instead of double-putting", " it", " * CVE-2026-72129", " - nvmet-rdma: handle inline data with a nonzero offset", " * CVE-2026-72130", " - nvmet-auth: reject short AUTH_RECEIVE buffers", " * CVE-2026-64551", " - sctp: validate STALE_COOKIE cause length before reading staleness", " * CVE-2026-72137", " - xfrm: nat_keepalive: avoid double free on send error", " * CVE-2026-72139", " - tcp: defer md5sig_info kfree past RCU grace period in tcp_connect", " * CVE-2026-72191", " - ntfs3: validate split-point offset in indx_insert_into_buffer", " * CVE-2026-72192", " - ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head", " * CVE-2026-72194", " - fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow", " * CVE-2026-72217", " - SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing", " * CVE-2026-72220", " - sunrpc: harden rq_procinfo lifecycle to prevent double-free", " * CVE-2026-72221", " - sunrpc: wait for in-flight TLS handshake callback when cancel loses race", " * CVE-2026-72222", " - sunrpc: pin svc_xprt across the asynchronous TLS handshake callback", " * CVE-2026-72226", " - batman-adv: tt: prevent TVLV OOB check overflow", " * CVE-2026-72234", " - batman-adv: access unicast_ttvn skb->data only after skb realloc", " * CVE-2026-72251", " - netfilter: nf_nat_sip: reload possible stale data pointer", " * CVE-2026-72277", " - KVM: arm64: nv: Inject SEA if kvm_translate_vncr() can't resolve PFN", " - KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory", " * CVE-2026-72279", " - KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR", " * CVE-2026-72288", " - KVM: arm64: vgic: Handle race between interrupt affinity change and LPI", " disabling", " * CVE-2026-72289", " - KVM: arm64: vgic: Check the interrupt is still ours before migrating it", " * CVE-2026-72296", " - net: ife: require ETH_HLEN to be pullable in ife_decode()", " * CVE-2026-72299", " - tipc: restrict socket queue dumps in enqueue tracepoints", " * CVE-2026-72317", " - SUNRPC: pin upper rpc_clnt across the TLS connect_worker", " * CVE-2026-72318", " - cifs: validate DFS referral string offsets", " * CVE-2026-72319", " - ipvs: fix PMTU for GUE/GRE tunnel ICMP errors", " - ipvs: ensure inner headers in ICMP errors are in headroom", " * CVE-2026-72320", " - netfilter: nft_lookup: fix catchall element handling with inverted", " lookups", " * CVE-2026-72322", " - ipv6: mcast: Fix potential UAF in MLD delayed work", " * CVE-2026-72323", " - ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()", " * CVE-2026-64541", " - net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket", " * CVE-2026-72339", " - qede: fix off-by-one in BD ring consumption on build_skb failure", " * CVE-2026-72348", " - netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop", " * CVE-2026-72351", " - gue: validate REMCSUM private option length", " * CVE-2026-72366", " - netfs: Fix netfs_create_write_req() to handle async cache object", " creation", " * CVE-2026-72381", " - ksmbd: fix use-after-free of fp->owner.name in durable handle owner", " check", " * CVE-2026-72393", " - eth: fbnic: don't cache shinfo across skb realloc", " * CVE-2026-72398", " - sctp: add INIT verification after cookie unpacking", " * CVE-2026-72399", " - net: enetc: check the number of BDs needed for xdp_frame", " * CVE-2026-64530", " - net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle", " * CVE-2026-72422", " - ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2", " NEGOTIATE", " * CVE-2026-72429", " - ipv6: ioam: fix type confusion of dst_entry", " * CVE-2026-72436", " - 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", " * CVE-2026-72451", " - xfrm: Fix xfrm state cache insertion race", " * CVE-2026-72466", " - xprtrdma: Fix bcall rep leak and unbounded peek", " * CVE-2026-72472", " - nfs: use nfsi->rwsem to protect traversal of the file lock list", " * CVE-2026-72473", " - 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", " * CVE-2026-72491", " - net/9p: fix race condition on rdma->state in trans_rdma.c", " * CVE-2026-72495 // CVE-2026-72501", " - RDMA/bnxt_re: Move the UAPI methods to a dedicated file", " * CVE-2026-74255", " - tipc: fix UAF in tipc_l2_send_msg()", " * CVE-2026-74267", " - net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek", " before restoring qlen", " * CVE-2026-74268", " - tcp: clear sock_ops cb flags before force-closing a child socket", " * CVE-2026-74287", " - sctp: validate embedded address parameter length", " * CVE-2026-74310", " - vhost/net: complete zerocopy ubufs only once", " * CVE-2026-74345", " - RDMA/siw: Fix endpoint/socket association handling", " * CVE-2026-74361", " - nvme: fix FDP fdpcidx bounds check", " * CVE-2026-74376", " - md/raid10: reset read_slot when reusing r10bio for discard", " * CVE-2026-74384", " - nvme-multipath: fix flex array size in struct nvme_ns_head", " * CVE-2026-74394", " - RDMA/srpt: fix integer overflow in immediate data length check", " * CVE-2026-74398", " - ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD", " * CVE-2026-74401", " - dlm: fix add msg handle in send_queue ordered", " * CVE-2026-74406", " - vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().", " * CVE-2026-74427", " - afs: Fix netns teardown to cancel the preallocation charger", " - afs: Fix further netns teardown to cancel the preallocation charger", " * CVE-2026-74428", " - rxrpc: Fix double unlock in rxrpc_recvmsg()", " * CVE-2026-74433", " - rxrpc: Fix UAF in rxgk_issue_challenge()", " * CVE-2026-74434", " - rxrpc: Don't move a peeked OOB message onto the pending queue", " * CVE-2026-74436", " - rxrpc: serialize kernel accept preallocation with socket teardown", " * CVE-2026-64535", " - nvmet-tcp: Fix potential UAF when ddgst mismatch", " * CVE-2026-74439", " - iommu/vt-d: Clear Present bit before tearing down scalable-mode context", " entry", " * CVE-2026-64534", " - nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error", " path", "" ], "package": "linux-riscv-7.0", "version": "7.0.0-38.38.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2165483, 2165484, 2165407, 2166547, 2166443, 2166356, 2165872, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165407, 2165040, 2161748, 2163508, 2163214, 2162904, 2162045, 2164967, 2160082, 2164504, 2156316, 2164716, 2164516, 2163375, 2162803, 2163062, 2132119, 2163293, 2160200, 2158858, 2162704, 2162695, 2164666, 2164666, 2163121 ], "author": "Sarah Emery ", "date": "Sun, 27 Sep 2026 00:11:21 +0200" } ], "notes": "linux-headers-7.0.0-38-generic version '7.0.0-38.38.1~24.04.1' (source package linux-riscv-7.0 version '7.0.0-38.38.1~24.04.1') was added. linux-headers-7.0.0-38-generic version '7.0.0-38.38.1~24.04.1' has the same source package name, linux-riscv-7.0, as removed package linux-headers-7.0.0-34-generic. As such we can use the source package version of the removed package, '7.0.0-34.34.1~24.04.1', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-image-7.0.0-38-generic", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": null }, "to_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-38.38.1~24.04.1", "version": "7.0.0-38.38.1~24.04.1" }, "cves": [ { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-68105", "url": "https://ubuntu.com/security/CVE-2026-68105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix kernel panic during driver load failure Avoid kernel panic if MES init fails during driver load. The KIQ ring is falsely marked as ready as ASICs that use MES, KIQ is owned by MES. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] Call Trace: gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280 __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53 (cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68109", "url": "https://ubuntu.com/security/CVE-2026-68109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68114", "url": "https://ubuntu.com/security/CVE-2026-68114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit e4d99e04b2e9b13b97d3b17804c735f62689db23)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68431", "url": "https://ubuntu.com/security/CVE-2026-68431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate minimum PDU size for transform requests The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68138", "url": "https://ubuntu.com/security/CVE-2026-68138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: serialize qdisc_rtab_list against concurrent get/put qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68082", "url": "https://ubuntu.com/security/CVE-2026-68082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix two unsafe bare decodes in decode_lockers() decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-08 10:16:00 UTC" }, { "cve": "CVE-2026-68159", "url": "https://ubuntu.com/security/CVE-2026-68159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68163", "url": "https://ubuntu.com/security/CVE-2026-68163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_vma_mapped: fix device-private PMD handling Commit 65edfda6f3f2 (\"mm/rmap: extend rmap and migration support device-private entries\") introduced the concept of device-private PMD entries, but did not correctly update the rmap walk code to account for them. As a result, when page_vma_mapped_walk() encounters device-private PMD entries, it takes no action other than to acquire the PMD lock and exit. However this is highly problematic for two reasons - firstly, device private entries possess a PFN so check_pmd() needs to be called to ensure an overlapping PFN range. Secondly, and more importantly, if PVMW_MIGRATION is set the caller assumes the returned entry is a migration entry, resulting in memory corruption when the caller tries to interpret the device private entry as such. In addition, commit 146287290023 (\"mm/huge_memory: implement device-private THP splitting\") allowed device private PMDs to be split like THP mappings, but again did not update this code path. As a result, we might race a PMD split prior to acquiring the PMD lock. This patch addresses all of these issues by invoking check_pmd(), ensuring PMVW_MIGRATION is not set and checks whether a split raced us we do for PMD THP and migration entries. Instead of checking for a subset of the cases after taking the pmd_lock(), put device-private along with pmd_trans_huge() and pmd_is_migration_entry(). Also remove thp_migration_supported() as it is already guarded by pmd_is_migration_entry(). [akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68166", "url": "https://ubuntu.com/security/CVE-2026-68166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: prevent registration of special VMAs Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68170", "url": "https://ubuntu.com/security/CVE-2026-68170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix stale skb->sk reference on subflow close The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68177", "url": "https://ubuntu.com/security/CVE-2026-68177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Delay module ref count for \"enable_event\" trigger Triggers are now delayed from freeing, but can still be triggered until after the RCU grace period has ended. The freeing of the enable_event data is put into the private_data_free() callback, but the put of the module refcount is done immediately. It is possible that if a module is removed that has an event that would enable (or disable) it is still active, it can read the data of the module after it is removed causing a use-after-free bug. Move the trace_event_put_ref() that releases the module into the delayed callback so that the module can not be removed until any reference to its events are finished.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68191", "url": "https://ubuntu.com/security/CVE-2026-68191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix NULL pointer dereference in rhash table destroy When unbinding the ath12k driver, kernel NULL pointer dereferences occur in irq_work_sync() called from rhashtable_destroy(). Two hash tables are affected: 1. ath12k_link_sta hash table in ath12k_base 2. ath12k_dp_link_peer hash table in ath12k_dp The issue happens because the destroy functions are called unconditionally in cleanup paths, but the hash tables are only initialized late in their respective init functions. If the device was never fully started or if the init functions failed before initializing the hash tables, the pointers will be NULL. The issues are always reproducible from a VM because the MSI addressing initialization is failing. Call trace for ath12k_link_sta_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_link_sta_rhash_tbl_destroy+0x19/0x40 [ath12k] ath12k_core_stop+0xe/0x80 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Call trace for ath12k_dp_link_peer_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_dp_link_peer_rhash_tbl_destroy+0x29/0x50 [ath12k] ath12k_dp_cmn_device_deinit+0x21/0x140 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Fix this by adding NULL checks before calling rhashtable_destroy() in both destroy functions. The NULL check approach was chosen because the rhashtable pointer serves as the initialization state indicator. The init can fail at various points, leaving some components uninitialized. Checking the pointer directly is simpler than adding separate state flags that would need synchronization.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64586", "url": "https://ubuntu.com/security/CVE-2026-64586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: drain bus_reset work on device removal brcmf_fw_crashed() and the debugfs \"reset\" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs \"reset\" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. 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-68208", "url": "https://ubuntu.com/security/CVE-2026-68208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: Fix the error code of devm_kzalloc() in vip_probe_slice() In vip_probe_slice(), the error check for devm_kzalloc() incorrectly uses PTR_ERR_OR_ZERO() which returns 0 for NULL pointer. Return -ENOMEM for devm_kzalloc() failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68224", "url": "https://ubuntu.com/security/CVE-2026-68224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mali-c55: Fix possible ERR_PTR in enable_streams The media_pad_remote_pad_unique() function returns either a valid pointer or an ERR_PTR() on failure (-ENOTUNIQ if multiple links are enabled, -ENOLINK if no connected pad is found). The return value was assigned directly to isp->remote_src and dereferenced in the next line without checking for errors, which could lead to an ERR_PTR dereference. Add proper error checking with IS_ERR() before dereferencing the pointer. Also set isp->remote_src to NULL on error to maintain consistency with other error paths in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68237", "url": "https://ubuntu.com/security/CVE-2026-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: fix indefinite fence wait during GPU reset pre_reset only force-completes fences of MAPPED queues. A queue in any other state (e.g. mid-eviction) keeps its last_fence pending; after a GPU reset that fence never signals, so the eviction/suspend worker and process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and wedge the machine: INFO: task kworker/6:28 blocked for more than 120 seconds. Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu] Call Trace: dma_fence_wait_timeout+0x7e/0x130 amdgpu_userq_evict+0x67/0x140 [amdgpu] amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu] process_scheduled_works+0xa6/0x420 Force-complete every queue's fence regardless of state. The unmap and mark-hung step stays gated on MAPPED, since unmapping a queue that is not mapped is invalid. (cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68240", "url": "https://ubuntu.com/security/CVE-2026-68240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: publish dpagemap early to avoid device mapping leak on error drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68242", "url": "https://ubuntu.com/security/CVE-2026-68242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix NULL deref on sched_engine alloc failure Avoid using intel_context_put() before intel_context_init() in execlists_create_virtual() as the kref_put() inside would lead to NULL deref on the IOCTL path when sched_engine allocation fails. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68254", "url": "https://ubuntu.com/security/CVE-2026-68254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: require valid min/max vfreq for VRR Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68436", "url": "https://ubuntu.com/security/CVE-2026-68436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use kvzalloc to allocate struct dc struct dc has grown large over time (most of it the two inlined dc_scratch_space copies) and now sits close to the page allocator's 4 MiB contiguous allocation limit. Its actual size is not fixed by the source alone, it also depends on the compiler and the .config, so it can easily cross 4 MiB, e.g. with a newer GCC or a config change. dc_create() allocates it with kzalloc(). Once struct dc exceeds 4 MiB the request is rounded up to order 11 (8 MiB), which is above MAX_PAGE_ORDER, so the page allocator warns and returns NULL. dc_create() then fails, DM init fails and amdgpu probe aborts with -EINVAL: WARNING: mm/page_alloc.c:5197 at __alloc_frozen_pages_noprof+0x2f9/0x380 dc_create+0x38/0x660 [amdgpu] amdgpu_dm_init+0x2d9/0x510 [amdgpu] dm_hw_init+0x1b/0x90 [amdgpu] amdgpu_device_init.cold+0x150d/0x1e13 [amdgpu] amdgpu_driver_load_kms+0x19/0x80 [amdgpu] amdgpu_pci_probe+0x1e2/0x4c0 [amdgpu] dc_create() then returns NULL and DM init fails, which aborts the whole GPU init and makes amdgpu probe fail with -EINVAL (\"hw_init of IP block failed -22\"), leaving the display unusable. The subsequent amdgpu_irq_put() warnings during teardown are just fallout of unwinding a half-initialized device. struct dc is a software-only bookkeeping structure that is never handed to hardware DMA and is only ever kept as an opaque pointer, so it does not require physically contiguous memory. Allocate it with kvzalloc() (and free it with kvfree()) so that the allocator can fall back to vmalloc() when a contiguous allocation of that size is not available, which also avoids the MAX_PAGE_ORDER warning entirely. v2: - Rebase to amd-staging-drm-next. (cherry picked from commit 991e0516a8072f2292681c6ae98a924ab0e32575)", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68447", "url": "https://ubuntu.com/security/CVE-2026-68447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size from hardware without bounding it to the allocated BO region. If the HW field is larger than the queue's control stack allocation, memcpy reads past the BO into adjacent GTT memory and can leak kernel data to userspace. Store the page-aligned control stack BO size in mqd_manager and clamp checkpoint copies and reported checkpoint sizes to min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound for multi-XCC v9.4.3 checkpoint layout. (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3)", "cve_priority": "high", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68264", "url": "https://ubuntu.com/security/CVE-2026-68264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: Reset current_op in xe_pt_update_ops_init() xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it. After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind. Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry. Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(). v2 (Matt): - Add details in commit message. - Add Fixes tag and Cc to stable@vger.kernel.org (cherry picked from commit 046045543e530605c441063535e7dca0075369a6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68265", "url": "https://ubuntu.com/security/CVE-2026-68265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO's tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference (cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68267", "url": "https://ubuntu.com/security/CVE-2026-68267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists Unconditionally whitelisting OA registers is a security violation. Set RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers don't get whitelisted by default after probe, gt reset, resume and engine reset. (cherry picked from commit 90511bdcfda97211c01f1d945d4ea616578d8fca)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68273", "url": "https://ubuntu.com/security/CVE-2026-68273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68274", "url": "https://ubuntu.com/security/CVE-2026-68274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix buffer overflow in steered register list allocation The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt->fuse_topo.g_dss_mask, ...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68283", "url": "https://ubuntu.com/security/CVE-2026-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free freeing trigger private data Commit 61d445af0a7c (\"tracing: Add bulk garbage collection of freeing event_trigger_data\") moved the kfree() of event_trigger_data to a kthread that runs tracepoint_synchronize_unregister() before freeing. That removed the synchronization the trigger .free callbacks used to get implicitly and inline from trigger_data_free(). event_hist_trigger_free(), event_hist_trigger_named_free() and event_enable_trigger_free() free their satellite data (hist_data, cmd_ops, enable_data) right after trigger_data_free() returns. With the synchronization now deferred to the kthread, a concurrent tracepoint handler can still reach that data through the list_del_rcu()'d trigger, causing a use-after-free. The histogram teardown must stay synchronous: remove_hist_vars() and unregister_field_var_hists() have to detach a synthetic event from the histogram before the trigger-removal write returns, otherwise a following command races in and the synthetic-event removal fails with -EBUSY, as the trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait with the correct barrier - tracepoint_synchronize_unregister(), matching the free kthread - before freeing. The enable trigger has no such synchronous requirement, and a blocking synchronize there would re-serialize the path that commit deliberately deferred. Give it an optional private_data_free() callback that the free kthread runs after its grace period, and free enable_data from there.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68286", "url": "https://ubuntu.com/security/CVE-2026-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68287", "url": "https://ubuntu.com/security/CVE-2026-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix size calculations for 64-bit attributes net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68288", "url": "https://ubuntu.com/security/CVE-2026-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68289", "url": "https://ubuntu.com/security/CVE-2026-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68291", "url": "https://ubuntu.com/security/CVE-2026-68291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix max_vport related crash on allocation error during init Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000 [ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000 [ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20 [ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000 [ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0 [ 320.417385] PKRU: 55555554 [ 320.417398] Call Trace: [ 320.417412] [ 320.417429] pci_device_remove+0x42/0xb0 [ 320.417459] device_release_driver_internal+0x1a9/0x210 [ 320.417492] driver_detach+0x4b/0x90 [ 320.417516] bus_remove_driver+0x70/0x100 [ 320.417539] pci_unregister_driver+0x2e/0xb0 [ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0 [ 320.417592] ? kmem_cache_free+0x31e/0x550 [ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190 [ 320.417644] ? do_syscall_64+0x38/0x6b0 [ 320.417665] do_syscall_64+0xc8/0x6b0 [ 320.417683] ? clear_bhb_loop+0x30/0x80 [ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 320.417727] RIP: 0033:0x7f963bb30beb", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68303", "url": "https://ubuntu.com/security/CVE-2026-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hvs/v3d: Fix null dereference in unbind The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68312", "url": "https://ubuntu.com/security/CVE-2026-68312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and cifs_close_deferred_file_under_dentry(), when a pending deferred close is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to add the file to the local processing list may fail under memory pressure. The loop breaks immediately, but the cancelled work is no longer pending (it would have called _cifsFileInfo_put()), and the cfile is never added to file_head for processing. The cifsFileInfo reference and the open server handle both leak. Fix by saving the cfile that failed allocation in a local variable, breaking as before, and calling _cifsFileInfo_put() on it after releasing the lock. Any files later in the iteration are unaffected since their deferred work is still pending and will fire normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68316", "url": "https://ubuntu.com/security/CVE-2026-68316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Fix element size accounting for cmd stream validation There are 2 issues with the element size handling in the command stream validation which result in too small of a size calculated when the element size is 16/32/64 bits. For NHWC format, the element size is simply missing from the calculation. The bitfield for the element size is different between IFM/IFM2 and OFM. IFM and IFM2 encode the precision in parameter bits 2:3, while OFM uses bits 1:2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68440", "url": "https://ubuntu.com/security/CVE-2026-68440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix heap overflow when reading module EEPROM txgbe_read_eeprom_hostif() always copies round_up(length, 4) bytes into the caller buffer, which ethtool allocates with exactly 'length' bytes. A non-4-aligned length therefore causes an out-of-bounds write. Copy only the remaining bytes on the final dword instead.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68323", "url": "https://ubuntu.com/security/CVE-2026-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: serialize udp bearer replicast list updates tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68441", "url": "https://ubuntu.com/security/CVE-2026-68441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected. This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d (\"bpf: add bpf_redirect() helper\"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available. commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs. Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a wrapper around tcf_classify() for use by qdisc classify functions and tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT, the wrapper converts it to TC_ACT_SHOT, dropping the packet rather than letting it continue silently. Dropping is preferred over letting the packet through because the user immediately sees packet loss. Silently passing the packet through would hide the problem and leave the user wondering why their redirect is not working. The clsact fast path, tc_run() continues to call tcf_classify() directly and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by sch_handle_egress/ingress() calling skb_do_redirect() as before.", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68337", "url": "https://ubuntu.com/security/CVE-2026-68337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject redirect helpers without a bpf_net_context The bpf_redirect*() helpers and skb_do_redirect() obtain the per-task bpf_redirect_info via bpf_net_ctx_get_ri(), which dereferences the current->bpf_net_context unconditionally. That context is established on the paths that run tc BPF such as sch_handle_{ingress,egress}(), *except* for the case where {cls,act}_bpf was attached to a proper qdisc. A program running from there reaches the NULL deref in two ways: * It calls bpf_redirect() directly, which dereferences the context at the top of the helper: tc qdisc add dev eth0 root handle 1: red limit 1MB min 10KB max 20KB \\ avpkt 1000 burst 100 qevent early_drop block 10 tc filter add block 10 pref 1 bpf obj redirect.o * It simply returns TC_ACT_REDIRECT without helper call: tcf_qevent_handle() then dispatches to skb_do_redirect(), which dereferences the context Rather than extending bpf_net_context management into the qdisc path, make the redirect helpers refuse to operate when no context exists, and have tcf_qevent_handle() drop a TC_ACT_REDIRECT verdict instead of calling skb_do_redirect(). Previous behaviour was a crash, so nothing regresses by not supporting it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68345", "url": "https://ubuntu.com/security/CVE-2026-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm_mpam: guard MBWU state before adding it to garbage __destroy_component_cfg() adds each RIS mbwu_state object to the MPAM garbage list when destroying component configuration. However, mbwu_state is allocated per RIS and only for RISes with MBWU monitors. A component can therefore have comp->cfg allocated while some RISes still have ris->mbwu_state set to NULL. Passing a NULL mbwu_state to add_to_garbage() dereferences the NULL pointer inside the macro. Skip RISes that do not have an mbwu_state object before adding them to the garbage list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68347", "url": "https://ubuntu.com/security/CVE-2026-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68375", "url": "https://ubuntu.com/security/CVE-2026-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle partially initialized auxiliary devices bnxt_aux_devices_init() calls auxiliary_device_init() before all fields used by bnxt_aux_dev_release() are initialized. After auxiliary_device_init() succeeds, later errors must unwind with auxiliary_device_uninit(), which invokes the release callback. The release callback assumes that aux_priv->id, aux_priv->edev, edev->net and edev->ulp_tbl are all populated. If allocation fails after auxiliary_device_init(), the release path can otherwise dereference or clear partially initialized state. Allocate and attach the bnxt_en_dev and ULP table before calling auxiliary_device_init(), so the release callback only sees a fully initialized auxiliary private object. If auxiliary_device_init() itself fails, free those allocations directly because device_initialize() has not run and the release callback will not be invoked. 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-68382", "url": "https://ubuntu.com/security/CVE-2026-68382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Hold device ref until queue teardown completes GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock. Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending. Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work. With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. Replace the fini wait with an assertion and remove the unused fini_wq. v2: - Rebase v3: - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt) - Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt) - Drop separate deferred drm_dev_put worker. - Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini(). v4: - Replace the guc_submit_sw_fini() wait with an assertion and remove the now-unused fini_wq. (sashiko) v5: - Move destroy work to a module-lifetime Xe workqueue instead of system_dfl_wq. (Matt) - Flush the module-lifetime destroy workqueue during PCI remove to preserve the old device-remove wait semantics. v6: - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid letting it outlive the xe_device/drm_device. (Sashiko) - Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work can be queued from the reclaim path. v7: - Drop the per-device xe->destroy_wq and use the module-level destroy WQ for SVM pagemap destroy as well. (Matt) - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*() helpers because the WQ is no longer exec-queue specific. (Matt) v8: - Rebase. v9: - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM destroy_wq because it can be queued from reclaim and embeds the dev_pagemap used by devres teardown. (Sashiko) - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM from it. - Update the module-WQ kdoc to document the GuC/SVM split. v10: - Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the workqueue allocation warning. v11: - Drop the SVM pagemap destroy comment as it was revision-specific. (Thomas) v12: - Rebase. (cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68383", "url": "https://ubuntu.com/security/CVE-2026-68383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Keep scheduler timeline name alive The scheduler keeps a pointer to the timeline name, but q->name is freed with the exec queue while scheduler fences can still reference it. Store the name in struct xe_guc_exec_queue so it shares the scheduler's RCU-deferred lifetime. (cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68390", "url": "https://ubuntu.com/security/CVE-2026-68390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups hci_conn_params_lookup requires hdev->lock be held, otherwise the list iteration or param access is not safe. Hold hdev->lock for params lookups in hci_sync.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-2026-68404", "url": "https://ubuntu.com/security/CVE-2026-68404", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: use wiphy work for socket owner autodisconnect nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68367", "url": "https://ubuntu.com/security/CVE-2026-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: synchronize delayed set_alt with teardown The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68095", "url": "https://ubuntu.com/security/CVE-2026-68095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse-uring: fix race between registration and connection abortion This fixes this race: - thread a: io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref yet - thread b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() is a no-op due to queue ref being 0 - thread a: grabs the queue_ref, queue_ref is now 1, rest of fuse_uring_do_register() logic executes - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs and calls \"wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);\" The abort/unmount thread will hang indefinitely in unkillable state as nothing will decrement queue_refs or wake stop_waitq, and the ring, queue, and ent are leaked. Fix this by checking fch->connected under fch->lock after the created ent has grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either release the queue ref and wake up stop_waitq (in case fuse_chan_wait_aborted() is already waiting) in fuse_uring_do_register() when we detect !fch->connected, or if the connection is aborted after the check, it is guaranteed that the async teardown worker will be running in the background cleaning up ents and decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-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-68173", "url": "https://ubuntu.com/security/CVE-2026-68173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: wait on ublk_dev_ready() instead of ub->completion ub->completion is only re-armed by a successful START_USER_RECOVERY. If the ublk server sends END_USER_RECOVERY without one - e.g. its START failed with -EBUSY and the error was ignored - the wait is satisfied by the stale completion of the previous recovery cycle, and the device is marked LIVE and the requeue list kicked while the FETCH stream is still running and ubq->canceling is still set. The kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it again via __ublk_abort_rq(), and after the last FETCH clears ->canceling nothing ever kicks the requeue list again: the request is stranded there while holding its tag. If it is the flush machinery's flush_rq, every subsequent fsync piles up in uninterruptible sleep and teardown hangs on tag draining. This matches a report of a lost PREFLUSH with ext4 on top of ublk after daemon crash recovery. ub->completion is an edge-triggered latch used as a proxy for the level condition \"every queue has fetched all I/O commands\", which can regress (F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop it and wait on the real condition instead: the new helper ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then re-checks it under ub->mutex, waiting again on regression, and returns with the mutex held and readiness guaranteed. Readiness becomes true in the same ub->mutex critical section that clears the last queue's ->canceling, so END_USER_RECOVERY marks the device LIVE and kicks the requeue list strictly after ->canceling clears. The wait stays interruptible, so a server whose daemon died can still be signalled out. For ublk_ctrl_start_dev() this replaces the fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting until the device is ready again.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68113", "url": "https://ubuntu.com/security/CVE-2026-68113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68118", "url": "https://ubuntu.com/security/CVE-2026-68118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: challenge ACK for non-exact RST in SYN-RECEIVED The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68120", "url": "https://ubuntu.com/security/CVE-2026-68120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtase: Workaround for TX hang caused by hardware packet parsing The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission.", "cve_priority": "medium", "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-68122", "url": "https://ubuntu.com/security/CVE-2026-68122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix peer refcount leak in TCP error paths When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&peer->tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object. The race window: CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error): ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2 schedule_work() <- queued schedule_work() <- NO-OP (work already pending) ovpn_tcp_peer_del_work runs: ovpn_peer_del() ovpn_peer_put() <- refcnt+1 <- peer never freed Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68128", "url": "https://ubuntu.com/security/CVE-2026-68128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: reject out-of-range ptype in ice_parser_profile_init set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from providing ptype >= 1024 through VIRTCHNL, resulting in a write past the end of the bitmap and a kernel page fault. Reproduced with a custom kernel module injecting a crafted VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1. crash_parser: ice_parser_profile_init @ ffffffffc0d61b60 crash_parser: setting ptype=0xffff (max valid=1023) crash_parser: calling ice_parser_profile_init -- expect OOB crash! BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace: ? __pfx_ice_parser_profile_init+0x10/0x10 [ice] crash_init+0x127/0xff0 [crash_parser] do_one_initcall+0x45/0x310 do_init_module+0x64/0x270 init_module_from_file+0xcc/0xf0 idempotent_init_module+0x17b/0x280 __x64_sys_finit_module+0x6e/0xe0 Bail out early with -EINVAL when ptype is out of range.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68132", "url": "https://ubuntu.com/security/CVE-2026-68132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: super: fix emergency thaw deadlock on frozen block devices do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68133", "url": "https://ubuntu.com/security/CVE-2026-68133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP Call Trace during PTP release If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will result in the following PTP release call trace during driver unload: kernel BUG at lib/list_debug.c:52! ice_ptp_release+0x332/0x3c0 [ice] ice_deinit_features.part.0+0x10e/0x120 [ice] ice_remove+0x100/0x220 [ice] This was observed when passing PF1 through to a VM. ice_ptp_init() fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT. Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and returning without error, preventing the invalid state transition to ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from ICE_PTP_RESETTING after a failed rebuild.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68134", "url": "https://ubuntu.com/security/CVE-2026-68134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: ptp_s390: Add missing facility check Only register the physical clock when facility 28 is installed and PTFF QAF returns that PTFF QPT is available.", "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-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-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-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-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-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-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-68150", "url": "https://ubuntu.com/security/CVE-2026-68150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/super: fix emergency thaw double-unlock of s_umount do_thaw_all() iterates over all superblocks via __iterate_supers() with SUPER_ITER_EXCL, which acquires s_umount exclusively before calling the callback and releases it afterwards. However, the callback do_thaw_all_callback() calls thaw_super_locked() which unconditionally releases s_umount on every code path. This results in a second unlock attempt in __iterate_supers() that corrupts the rwsem state, triggering a DEBUG_RWSEMS warning: [ 182.601148] sysrq: Emergency Thaw of all frozen filesystems [ 182.601865] ------------[ cut here ]------------ [ 182.602375] DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff99b1011e5870, owner = 0x0, curr 0xffff99b101b06c80, list not empty [ 182.603817] WARNING: kernel/locking/rwsem.c:1412 at up_write+0xa3/0x170, CPU#2: kworker/2:1/53 [ 182.604578] Modules linked in: [ 182.604864] CPU: 2 UID: 0 PID: 53 Comm: kworker/2:1 Not tainted 7.2.0-rc4-00001-gbd3bd93ea98a-dirty #4 PREEMPT(lazy) [ 182.605711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014 [ 182.606417] Workqueue: events do_thaw_all [ 182.606750] RIP: 0010:up_write+0xaf/0x170 [ 182.607076] Code: 19 3a 92 48 0f 44 c2 48 8b 55 08 48 8b 55 00 4c 8b 45 08 48 8b 55 00 48 8d 3d ad 91 e0 01 48 8b 4d 20 50 48 c7 c6 f0 8c 26 92 <67> 48 0f b9 3a e8 d7 93 4e 00 58 eb 81 48 83 7f 18 00 48 c7 c2 8d [ 182.608563] RSP: 0018:ffffb670001d7e08 EFLAGS: 00010246 [ 182.609007] RAX: ffffffff92349e8d RBX: 0000000000000000 RCX: ffff99b1011e5870 [ 182.609595] RDX: 0000000000000000 RSI: ffffffff92268cf0 RDI: ffffffff92914d10 [ 182.610283] RBP: ffff99b1011e5870 R08: 0000000000000000 R09: ffff99b101b06c80 [ 182.610847] R10: ffff99b10139a808 R11: fefefefefefefeff R12: 0000000000000000 [ 182.611414] R13: ffffffff90cf74d0 R14: 0000000000000000 R15: ffff99b1011e5800 [ 182.612009] FS: 0000000000000000(0000) GS:ffff99b1eaaee000(0000) knlGS:0000000000000000 [ 182.612670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 182.613146] CR2: 00000000005c631c CR3: 00000000013ee000 CR4: 00000000000006f0 [ 182.613722] Call Trace: [ 182.613946] [ 182.614130] __iterate_supers+0x128/0x150 [ 182.614463] do_thaw_all+0x1b/0x30 [ 182.614759] process_scheduled_works+0xbb/0x3f0 [ 182.615150] ? __pfx_worker_thread+0x10/0x10 [ 182.615499] worker_thread+0x129/0x270 [ 182.615816] ? __pfx_worker_thread+0x10/0x10 [ 182.616201] kthread+0xe2/0x120 [ 182.616469] ? __pfx_kthread+0x10/0x10 [ 182.616792] ret_from_fork+0x15b/0x240 [ 182.617115] ? __pfx_kthread+0x10/0x10 [ 182.617426] ret_from_fork_asm+0x1a/0x30 [ 182.617761] [ 182.617968] ---[ end trace 0000000000000000 ]--- [ 182.618412] Emergency Thaw complete Fix this by switching to SUPER_ITER_UNLOCKED and acquiring s_umount in the callback via super_lock_excl() before calling thaw_super_locked(). This matches the locking pattern expected by thaw_super_locked() and eliminates the double unlock. While at it, remove the dead 'return;' at the end of do_thaw_all_callback().", "cve_priority": "low", "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-68152", "url": "https://ubuntu.com/security/CVE-2026-68152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: fix use-after-free in AMT delayed works When an AMT device is removed, pending delayed works can still access the freed amt_dev structure, which may result in kernel crashes or memory corruption. amt_dev_stop() cancels req_wq and discovery_wq with cancel_delayed_work_sync(), but these works can be scheduled again from event_wq after the cancellation. This allows delayed works to access the freed amt_dev structure after the netdev has been released. The following is a simple race scenario: CPU0 CPU1 amt_dev_stop() cancel_delayed_work_sync() amt_event_work() mod_delayed_work(req_wq) free netdev req_wq accesses freed amt_dev Use disable_delayed_work_sync() in amt_dev_stop() to prevent req_wq and discovery_wq from being queued again and wait for running work items to complete. The delayed works are disabled after initialization in amt_newlink() and enabled only when the device is successfully opened. This keeps the delayed work lifecycle synchronized with the lifetime of the AMT device.", "cve_priority": "high", "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-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-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-68168", "url": "https://ubuntu.com/security/CVE-2026-68168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix afs_edit_dir_remove() to get, not find, block 0 Fix afs_edit_dir_remove() to use afs_dir_get_block() to get block 0 rather than afs_dir_find_block() as the latter caches the found block in the afs_dir_iter and may[*] switch out the page it's on if another afs_dir_find_block() is done. This parallels what afs_edit_dir_add() does. [*] There's more than one block per page.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68169", "url": "https://ubuntu.com/security/CVE-2026-68169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: userspace: fix use-after-free in get_local_id In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a \"not found\" sentinel.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68172", "url": "https://ubuntu.com/security/CVE-2026-68172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: make huge_ptep_get handled unaligned addresses huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma). The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned. On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map or into a hole, dereference a VA not mapped into the kernel pgtables and cause kernel panic. Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68174", "url": "https://ubuntu.com/security/CVE-2026-68174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix union collision of module and refcnt for dynamic events In 'struct trace_event_call', the 'module' pointer and the 'refcnt' atomic variable share the same memory space in a union. For dynamic events, the union member is 'refcnt', which acts as an active reference counter. When a dynamic event (such as kprobe, uprobe, fprobe, eprobe, or wprobe) has a non-zero reference count (e.g. due to active event triggers or perf attachments), its 'call->module' evaluates to a small non-zero integer instead of NULL. When filtering or setting events for a specific module (e.g., writing ':mod:' to 'set_event'), the code in '__ftrace_set_clr_event_nolock()' and 'update_event_fields()' reads 'call->module' directly without checking whether the event is dynamic. This causes the kernel to treat the small integer (refcnt) as a 'struct module' pointer, leading to a NULL/invalid pointer dereference (Oops) when dereferencing the module name. Fix this by ensuring that the 'TRACE_EVENT_FL_DYNAMIC' flag is checked before treating 'call->module' as a valid pointer in these code paths.", "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-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-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-68434", "url": "https://ubuntu.com/security/CVE-2026-68434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms Commit b1b4efea05a5 (\"serial: 8250_mid: Disable DMA for selected platforms\") replaced the dnv_board setup and exit callbacks with PTR_IF(false, ...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. Fix this by adding the missing NULL checks before calling the setup and exit callbacks.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17: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-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-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16: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-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-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-68198", "url": "https://ubuntu.com/security/CVE-2026-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix use-after-free in aggr_reset_state() The aggr_reset_state() function uses timer_delete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggr_module_destroy(). If the timer callback (aggr_timeout) is executing when aggr_reset_state() is called, the callback will continue to access aggr_conn fields like rx_tid[] and stat[] which may be freed immediately after by kfree(aggr_info->aggr_conn) in aggr_module_destroy(). Additionally, the timer callback can re-arm itself via mod_timer() while aggr_reset_state() is running, creating a more complex race condition. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "high", "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-68200", "url": "https://ubuntu.com/security/CVE-2026-68200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: don't re-enter an instance callback that is still running The userspace-driven timer (utimer) TRIGGER ioctl calls snd_timer_interrupt() directly with no serialization, so two threads triggering the same utimer can run snd_timer_interrupt() on one snd_timer concurrently. snd_timer_process_callbacks() drops timer->lock around each instance callback and marks the in-flight callback with the single SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that bit to drain an in-flight callback before freeing the instance. The bit cannot represent two concurrent callbacks: when a second interrupt re-queues an instance whose callback is still running, both run at once, the first to finish clears the bit, and the close-path drain then frees the instance (and its callback_data) while the other callback is still live - a use-after-free reachable by any user able to open /dev/snd/timer, both via a user timer instance and via a sequencer queue timer bound to the utimer. snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so a concurrent interrupt already observes it under the lock. Skip re-queuing an instance (and its slaves) to the ack/sack list while its callback is in flight; the accumulated pticks are delivered on the next tick, so no event is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68201", "url": "https://ubuntu.com/security/CVE-2026-68201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: drain a slave's callback before its master detaches it snd_timer_close_locked() drains the closing instance's own in-flight callback (IFLG_CALLBACK) before freeing it, but not its slaves'. When a master instance is closed, remove_slave_links() clears each slave's ->timer; the slave's own close then reads timer == NULL and takes the branch that skips the drain entirely (snd_timer_stop_slave() also no-ops on a NULL timer). So a slave whose callback is still running when the master is closed is freed underneath the live callback, leading to use-after-free. Drain the slaves too before remove_slave_links() severs them. snd_timer_stop() has already taken this instance off the active list, so no new slave callback can be queued. Take the slaves off the ack list so a pending one can't fire either, then wait for any that is already in flight.", "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-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-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-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-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-68211", "url": "https://ubuntu.com/security/CVE-2026-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32-dcmipp: 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. dcmipp_bytecap_start_streaming() returned -EINVAL when the source subdevice could not be resolved from the media graph, before pm_runtime_resume_and_get() and media_pipeline_start() had been called. The remaining error paths already converge on the err_buffer_done label, which calls dcmipp_bytecap_all_buffers_done(..., VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate err_pm_put / err_media_pipeline_stop 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": "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-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-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-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-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-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-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-68230", "url": "https://ubuntu.com/security/CVE-2026-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: amlogic-c3: Add validations for ae and awb config Avoid invalid memory access if the zones_num is bigger than zone_weight. This patch fixes the following smatch errors: drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max", "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-68232", "url": "https://ubuntu.com/security/CVE-2026-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path.", "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-68233", "url": "https://ubuntu.com/security/CVE-2026-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Shut down BO cache timer before teardown The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20: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-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-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-68238", "url": "https://ubuntu.com/security/CVE-2026-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Release VFCT ACPI table reference amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68239", "url": "https://ubuntu.com/security/CVE-2026-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Account for NULL and handle pages in ttm_pool_backup Pages in ttm_pool_backup can be NULL or backup handles (ttm_backup_page_ptr_is_handle()), neither of which can be passed to set_pages_array_wb() or freed. Add a dedicated WB pass before the dma/purge loop that walks allocations using the same i += num_pages stride, skipping NULL and handle entries, and calls set_pages_array_wb() once per contiguous run of real pages. Apply the same NULL/handle guard to the dma/purge loop. Fixes the following oops: Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI RIP: 0010:__cpa_process_fault+0xf8/0x770 RSP: 0018:ffffc90000a87718 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34 RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0 R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000 R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0 FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0 PKRU: 55555554 Call Trace: __change_page_attr_set_clr+0x989/0xe90 ? __purge_vmap_area_lazy+0x6c/0x3a0 ? _vm_unmap_aliases+0x250/0x2a0 set_pages_array_wb+0x7f/0x120 ttm_pool_backup+0x4c9/0x5b0 [ttm] ? dma_resv_wait_timeout+0x3b/0xf0 ttm_tt_backup+0x32/0x60 [ttm] ttm_bo_shrink+0x66/0x110 [ttm] xe_bo_shrink_purge+0x12b/0x1b0 [xe] xe_bo_shrink+0xbb/0x270 [xe] __xe_shrinker_walk+0xf7/0x160 [xe] xe_shrinker_walk+0x9d/0xc0 [xe] xe_shrinker_scan+0x11f/0x210 [xe] do_shrink_slab+0x13b/0x270 shrink_slab+0xf1/0x400 shrink_node+0x352/0x8a0 balance_pgdat+0x32c/0x700 kswapd+0x205/0x2f0 ? __pfx_autoremove_wake_function+0x10/0x10 ? __pfx_kswapd+0x10/0x10 kthread+0xd1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1b1/0x200 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68241", "url": "https://ubuntu.com/security/CVE-2026-68241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/mst: limit DP MST ESI service loop The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto. (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)", "cve_priority": "medium", "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-68245", "url": "https://ubuntu.com/security/CVE-2026-68245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only valid while the lock is still being held. Once xa_unlock_irqrestore is called and returned, the pointer is no longer under lock and is subject to modification. Since, the caller still dereferences vm->task_info in amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a use after unlock problem. Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid() through removing the amdgpu_vm_get_vm_from_pasid() function from amdgpu_vm.c and making the relevant code inline to hold the lock while it is still in use. (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)", "cve_priority": "high", "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-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-68252", "url": "https://ubuntu.com/security/CVE-2026-68252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68253", "url": "https://ubuntu.com/security/CVE-2026-68253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)", "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-68257", "url": "https://ubuntu.com/security/CVE-2026-68257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix 32-bit overflow in CWSR total size calculation total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68258", "url": "https://ubuntu.com/security/CVE-2026-68258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on CRIU restore queue type and mqd size We weren't checking whether the values provided in the private data in kfd CRIU restore were within bounds. For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it. For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations. (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)", "cve_priority": "low", "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-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-68266", "url": "https://ubuntu.com/security/CVE-2026-68266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68268", "url": "https://ubuntu.com/security/CVE-2026-68268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Return error on non-migratable faults requiring devmem Non-migratable faults that require devmem incorrectly jump to the 'out' label, which squashes the error code intended to be returned to the upper layers. Fix this by returning -EACCES instead. (cherry picked from commit c4508edb2c723de93717272488ea65b165637eac)", "cve_priority": "medium", "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-68270", "url": "https://ubuntu.com/security/CVE-2026-68270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Avoid possible truncation with calculating visible size Calculating the visible size of the system framebuffer can result in truncation of the result. The calculation uses 32-bit arithmetics, which can overflow if the values for height and stride are large. Fix the issue by multiplying with mul_u32_u32().", "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-68275", "url": "https://ubuntu.com/security/CVE-2026-68275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks up the bo_va for the buffer object in the caller's VM via amdgpu_vm_bo_find(), but uses the returned pointer without checking it. amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM, which is the normal case for a BO that has never been mapped. The result is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which expands to list_for_each_entry(mapping, &(bo_va)->valids, list) and dereferences bo_va, causing a NULL pointer dereference. This is reachable by any process able to issue the ioctl (render group) simply by requesting mapping info for an unmapped BO. Return -ENOENT when no bo_va is found, jumping to out_exec so the drm_exec context and GEM object reference are released. (cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68276", "url": "https://ubuntu.com/security/CVE-2026-68276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx: fix cleaner shader IB buffer overflow The cleaner shader sysfs path allocates a 16-dword (64 byte) IB but incorrectly fills (align_mask + 1) dwords. On GFX rings align_mask is 0xff, so the loop wrote 256 dwords into a 64-byte buffer, causing a kernel page fault. The IB only needs to be a minimal NOP shell to schedule the job; the cleaner shader itself is emitted on the ring via emit_cleaner_shader(). Fill 16 dwords to match the allocation. v2: Use ib_size_dw variable (Lijo) (cherry picked from commit bf21af331ebf72d0935fd70c73192414a422c03a)", "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-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-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-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-68282", "url": "https://ubuntu.com/security/CVE-2026-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: analogix_dp: Add missing error check for platform_get_resource() Add missing error check for platform_get_resource() return value to prevent NULL pointer dereference when memory resource is not available.", "cve_priority": "medium", "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-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-68292", "url": "https://ubuntu.com/security/CVE-2026-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues.", "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-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-68296", "url": "https://ubuntu.com/security/CVE-2026-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM Before commit 00d066a4d4ed (\"netdev_features: convert NETIF_F_LLTX to dev->lltx\"), NETIF_F_LLTX was set unconditionally in both __gre_tunnel_init() and ip6gre_tnl_init_features() alongside GRE_FEATURES: dev->features |= GRE_FEATURES | NETIF_F_LLTX; When that commit converted NETIF_F_LLTX to the dev->lltx flag, it placed 'dev->lltx = true' after the SEQ/CSUM early returns instead of before them. This causes GRE/GRETAP/ip6gre tunnels with SEQ or CSUM+encap to lose lockless TX, reintroducing _xmit_lock acquisition around their ndo_start_xmit. Since GRE xmit re-enters the stack via ip_tunnel_xmit(), holding _xmit_lock risks ABBA deadlock with the underlay device. CPU0 CPU1 ---- ---- lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); Fix by moving dev->lltx = true before the early returns in both functions, restoring the original unconditional behavior.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64575", "url": "https://ubuntu.com/security/CVE-2026-64575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: fix double sock release on batch realloc bpf_iter_tcp_batch() releases the current batch via bpf_iter_tcp_put_batch(), which drops the socket refs and rewrites each slot with the socket cookie, then grows the batch. cur_sk/end_sk are kept for bpf_iter_tcp_resume(), but on realloc failure the function returns ERR_PTR() before resume runs, leaving cur_sk < end_sk over slots that now hold cookies rather than sock pointers. bpf_iter_tcp_seq_stop() then calls bpf_iter_tcp_put_batch() again and dereferences a cookie as a struct sock. Empty the batch on the failure path so stop() does not release it again. The sockets were already freed by the first bpf_iter_tcp_put_batch(), so nothing leaks, and a later read() rescans the bucket from the start instead of skipping it. The sibling GFP_NOWAIT failure path still holds real socket references and is left for stop() to release. BUG: KASAN: null-ptr-deref in __sock_gen_cookie Read of size 8 at addr 0000000000000059 by task exploit ... __sock_gen_cookie (net/core/sock_diag.c:28) bpf_iter_tcp_put_batch (net/ipv4/tcp_ipv4.c:2918) bpf_iter_tcp_seq_stop (net/ipv4/tcp_ipv4.c:3270) bpf_seq_read (kernel/bpf/bpf_iter.c:205) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 entry_SYSCALL_64_after_hwframe Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68298", "url": "https://ubuntu.com/security/CVE-2026-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create() Commit 9e9787414882 (\"drm/xe/userptr: replace xe_hmm with gpusvm\") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a \"simple\" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). (cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4)", "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-68448", "url": "https://ubuntu.com/security/CVE-2026-68448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: check access to copy_file_range source with src mounter creds Commit 5dae222a5ff0c (\"vfs: allow copy_file_range to copy across devices\") allowed filesystems that implement the copy_file_range() f_op to decide if they want to access cross-sb copy from/to the same fs type. The same commit added checks to verify same sb copy for filesystems that implement ->copy_file_range() and do not support cross-sb copy at the time, namely, to ceph, fuse and nfs. The two remaining fs which implement ->copy_file_range(), cifs and overlayfs started to support cross-sb copy from this time. While overlayfs does support cross-sb copy when the two underlying files are on the same base fs, the copy operation on the two real files from two different overalyfs filesystems is performed with the mounter creds of the destination overlayfs and the read permission access hook for the source file was called with the wrong creds. This could cause either deny of access to copy which would otherwise be allowed (e.g. with splice) or allow read access to file which would otherwise be denied. Fix the latter case by explicitly verifying read access to source file with the source overlayfs mounter creds. The former case remains a quirk of cross-sb overlayfs copy, but userspace could fall back to regular copy so no harm done.", "cve_priority": "low", "cve_public_date": "2026-08-12 01:17: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-68307", "url": "https://ubuntu.com/security/CVE-2026-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix crash in reset link replay During reset recovery, mt7925_vif_connect_iter() replays firmware state for links tracked in mvif->valid_links. After MLO link changes or MCU timeout recovery, the driver bitmap can temporarily contain a link whose mac80211 bss_conf has already gone away. This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching the crash where x1, the second argument, is NULL: pc : mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] lr : mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] x2 : ffffff80a77f6018 x1 : 0000000000000000 x0 : ffffff8099402080 Call trace: mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common] Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA reset replay is unchanged because the helper still returns &vif->bss_conf for the legacy link.", "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-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-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-68311", "url": "https://ubuntu.com/security/CVE-2026-68311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: guard link STA in decap offload mt7925_sta_set_decap_offload() iterates over the vif valid_links mask when updating decap offload state for an MLO station. The station may not have a link STA for every valid link of the vif, so mt792x_sta_to_link() can return NULL for a link that belongs to the vif but not to the station. The function currently dereferences mlink before checking whether the link WCID is ready. If mlink is NULL, setting or clearing MT_WCID_FLAG_HDR_TRANS dereferences a NULL pointer. Skip links without a station link before touching mlink->wcid.", "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-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-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-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-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-68321", "url": "https://ubuntu.com/security/CVE-2026-68321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix FDIR filter leak on remove Perfect FDIR filters can be added while the interface is down and are kept on the software list for later restore. unregister_netdev() only calls ndo_stop when the device is up, so txgbe_fdir_filter_exit() in txgbe_close() is skipped in that case and the filters are leaked on driver remove. Free the filter list from txgbe_remove() as well.", "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-68330", "url": "https://ubuntu.com/security/CVE-2026-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix DMA direction for NPU mailbox buffer airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE, but some callers expect the NPU to write response data back into the same buffer: - airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into the buffer, then the caller reads it via memcpy() - airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back npu_stats_addr field in the response On non-cache-coherent architectures like EN7581 (Cortex-A53 without hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op — it does not invalidate the CPU cache. If the NPU-written cache line is still present in the CPU cache when the caller reads the buffer, the CPU observes stale data instead of the NPU response. This is a timing-sensitive bug: small mailbox buffers (~24 bytes) typically fit in a single cache line and may survive in the cache until the caller reads them, producing silent data corruption rather than a crash. The bug is more likely to trigger when the caller reads the response immediately after dma_unmap_single() without intervening cache-evicting operations. Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures dma_unmap_single() invalidates the CPU cache on non-coherent systems. The mailbox buffers are small so there is no performance concern.", "cve_priority": "low", "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-68332", "url": "https://ubuntu.com/security/CVE-2026-68332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix potential use-after-free in airoha_ppe_deinit() airoha_ppe_deinit() replaces the NPU pointer with NULL via rcu_replace_pointer() but does not wait for existing RCU readers to exit before calling ppe_deinit() and airoha_npu_put(). This can cause a use-after-free if a reader in an RCU read-side critical section still holds a reference to the NPU when it is freed. The init path (airoha_ppe_init) already calls synchronize_rcu() after rcu_assign_pointer(), but the deinit path introduced in commit 6abcf751bc08 (\"net: airoha: Fix schedule while atomic in airoha_ppe_deinit()\") omitted the matching barrier when switching from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer(). Add synchronize_rcu() before ppe_deinit() to ensure all existing RCU readers have completed before the NPU resources are released.", "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-68334", "url": "https://ubuntu.com/security/CVE-2026-68334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix io_thread race in rxrpc_wake_up_io_thread() rxrpc_wake_up_io_thread() checks local->io_thread before waking it, but then reloads the pointer for wake_up_process(). local->io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so the second load can see NULL even if the first load did not. Take a READ_ONCE() snapshot and use it for both the NULL check and the wake_up_process() call, as rxrpc_encap_rcv() already does.", "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-68341", "url": "https://ubuntu.com/security/CVE-2026-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix use after free in unlock_ovpn() unlock_ovpn() iterates over the release_list using llist_for_each_entry() and drops the peer reference inside the loop body via ovpn_peer_put(). If this drops the last reference, the peer is eventually freed. However, llist_for_each_entry() reads peer->release_entry.next in the loop advance expression, which runs after the body. By that time the peer may have already been freed, resulting in a use after free when advancing to the next list entry. Fix this by using llist_for_each_entry_safe(), which caches the next pointer before executing the loop body.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68342", "url": "https://ubuntu.com/security/CVE-2026-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: avoid putting unrelated P2P peer on socket release ovpn_peer_release_p2p() is called when an OVPN UDP socket is being destroyed. It checks the currently published P2P peer and releases it only if that peer still uses the socket being destroyed. A peer replacement can publish a new peer before the old UDP socket is destroyed. When the old socket destruction path runs afterwards, ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the new peer uses a different socket, the function takes the socket mismatch branch. That branch still calls ovpn_peer_put(peer). At this point, however, peer is the currently published replacement peer, not the peer associated with the socket being destroyed. Dropping its reference can free it while ovpn->peer still points to it, leading to later use-after-free accesses from the peer and socket cleanup paths. KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer object. In the reproducer, the object is allocated from ovpn_peer_new() via ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU callback processing. Observed access sites include ovpn_peer_remove(), ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn(). Fix this by returning from the socket mismatch branch without putting the peer.", "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-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-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-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-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-68356", "url": "https://ubuntu.com/security/CVE-2026-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: airoha: Prevent division by zero when clock frequency is zero clk_get_rate() can return 0 when the clock provider is not properly configured or the clock is unmanaged. The driver uses wdt_freq as a divisor directly in airoha_wdt_probe() to compute max_timeout and in airoha_wdt_get_timeleft() to compute the remaining time, which results in a division by zero. Add a check for wdt_freq == 0 in probe and return -EINVAL with dev_err_probe() to prevent the division by zero and provide a diagnostic message.", "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-68358", "url": "https://ubuntu.com/security/CVE-2026-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-kraken3) 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-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-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-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-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-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-68374", "url": "https://ubuntu.com/security/CVE-2026-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: sysfs: add lock to bos_descriptors_read() Add a lock to the function bos_descriptors_read(). This function accesses udev->bos, which could be simultaneously freed in usb_reset_and_verify_device(), a function that is commonly called in drivers all over the kernel.", "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-68378", "url": "https://ubuntu.com/security/CVE-2026-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions: - A pin is registered with two or more dpll devices (dpll_A, dpll_B) - The pin has ref_sync pairs with other pins - During unregistration of dpll_A's pins, a ref_sync partner pin is unregistered first, removing it from dpll_A->pin_refs - But since the partner pin is still registered with dpll_B, its dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT run and the partner stays in the pin's ref_sync_pins xarray - When the pin itself is then unregistered from dpll_A, the delete notification calls dpll_msg_add_pin_ref_sync() which finds the partner in ref_sync_pins, passes dpll_pin_available() (partner is still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A, partner) returns NULL because partner was already removed from dpll_A->pin_refs - The NULL priv pointer is passed to the driver's ref_sync_get callback, which dereferences it BUG: kernel NULL pointer dereference, address: 0000000000000034 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x] Call Trace: dpll_msg_add_pin_ref_sync+0xb8/0x200 dpll_cmd_pin_get_one+0x3b6/0x4b0 dpll_pin_event_send+0x72/0x140 __dpll_pin_unregister+0x5a/0x2b0 dpll_pin_unregister+0x49/0x70 Fix this by skipping ref_sync pins whose priv pointer cannot be resolved for the current dpll device.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68379", "url": "https://ubuntu.com/security/CVE-2026-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix TIME_WAIT socket reference leak on PSP policy failure Release the TIME_WAIT socket reference and jump to discard_it upon PSP policy failure in both IPv4 and IPv6 receive paths. This prevents a memory leak of tcp_tw_bucket structures.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68380", "url": "https://ubuntu.com/security/CVE-2026-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix use-after-free of mm_struct in job scheduler amdxdna_cmd_submit() stores current->mm in job->mm without holding any reference. aie2_sched_job_run() later access job->mm from the DRM scheduler worker thread. With only a raw pointer and no structural reference, the mm_struct can be freed before the scheduler runs the job. Fix this by calling mmgrab() to hold a structural mm_count reference for the lifetime of the job, paired with mmdrop() in every cleanup path.", "cve_priority": "high", "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-68384", "url": "https://ubuntu.com/security/CVE-2026-68384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits. - Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it. While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one. (cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68385", "url": "https://ubuntu.com/security/CVE-2026-68385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/checksum: Fix csum_partial() without vector facility Currently csum_partial() calls csum_copy() with copy=false and dst=NULL. On machines without the vector facility, csum_copy() falls back to cksm(dst, ...), causing the checksum to be calculated from address zero instead of the source buffer. The VX implementation already checksums data loaded from src. Make the fallback do the same by passing src to cksm().", "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-68387", "url": "https://ubuntu.com/security/CVE-2026-68387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: add locking for raw flags bitfield With commit 890e5198a6e5 (\"can: raw: use bitfields to store flags in struct raw_sock\") the formerly separate integer values have been integrated into a single bitfield. This led to a read-modify-write operation when changing a flag in raw_setsockopt() which now needs a locking to prevent concurrent access. Instead of adding a lock/unlock hell in each of the flag manipulations this patch introduces a wrapper for a new raw_setsockopt_locked() function analogue to the isotp_setsockopt[_locked]() approach in net/can/isotp.c [mkl: use Closes tag instead of Link]", "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-68393", "url": "https://ubuntu.com/security/CVE-2026-68393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: extend conn_hash lookup critical sections Using RCU-protected pointers outside the critical sections without refcount is incorrect and may result to UAF. Extend critical section to cover both hci_conn_hash lookup and use of the returned conn. Add surrounding rcu_read_lock() also when return value is not used, in preparation for RCU lockdep requirement to hci_lookup_le_connect(). This avoids concurrent deletion of the conn before we are done dereferencing it. Also, make sure to hold hdev->lock when accessing hdev->accept_list.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68394", "url": "https://ubuntu.com/security/CVE-2026-68394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update MGMT_OP_LOAD_CONN_PARAM queues conn_update_sync() when a single parameter update changes an existing LE central connection. The queued work currently stores a borrowed hci_conn_params entry from hdev->le_conn_params. A later LOAD_CONN_PARAM request can clear disabled parameters and free that entry before hci_cmd_sync_work() runs the queued callback. Do not keep the borrowed hci_conn_params pointer in queued work. Queue the hci_conn instead and hold a reference until the queued callback completes. When the work runs, revalidate that the connection is still present, look up the current hci_conn_params entry, and cancel the update if userspace removed that entry while the work was pending. Copy the interval values from the current params entry under hdev->lock, then drop the lock and keep using hci_le_conn_update_sync() to issue the update. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in conn_update_sync+0x2a/0xf0 [bluetooth] Read of size 1 at addr ffff88810c697126 by task kworker/u17:0/377 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 kasan_report+0xe0/0x110 conn_update_sync+0x2a/0xf0 [bluetooth] hci_cmd_sync_work+0x187/0x210 [bluetooth] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 Allocated by task 466: hci_conn_params_add+0xa6/0x240 [bluetooth] load_conn_param+0x4e1/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] Freed by task 474: kfree+0x313/0x590 hci_conn_params_clear_disabled+0x9b/0xc0 [bluetooth] load_conn_param+0x4bf/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth]", "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-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-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-68400", "url": "https://ubuntu.com/security/CVE-2026-68400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint memory access array and to comply with the FF-A spec instead of defaulting to `sizeof(struct ffa_mem_region)`. This requires moving `ffa_mem_region_additional_setup()` earlier in the setup flow. Also, add sanity checks to ensure the calculated descriptor offsets do not exceed `max_fragsize`.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68401", "url": "https://ubuntu.com/security/CVE-2026-68401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() Sashiko (locally) reports multiple out-of-bound issues in ffa_setup_and_transmit: 1) Writing ep_mem_access->reserved can write out of bounds for FFA versions < 1.2 as ffa_emad_size_get() returns 16 bytes in that case while reserved has an offset of 24. Instead of zeroing fields, memset the struct to zero first based on the FFA version. 2) Make sure there is enough size to write constituents. While at it, convert the only sizeof() in the driver that uses a type instead of variable.", "cve_priority": "high", "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-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-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-68409", "url": "https://ubuntu.com/security/CVE-2026-68409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: defer link RX stats percpu free to RCU sta_remove_link() frees a removed MLO link's RX stats percpu buffer right away, but defers only the link container to RCU: \tsta_info_free_link(&alloc->info); \tkfree_rcu(alloc, rcu_head); The RX fast path reads link_sta under rcu_read_lock and writes the percpu stats. A reader that resolved link_sta before the removal keeps the pointer. The container stays alive from the kfree_rcu, so the read still works. But the percpu block it points to is already freed. This needs uses_rss. That is when pcpu_rx_stats exists. The full STA teardown frees the deflink stats only after synchronize_net(). The link removal path had no such barrier. The race is hard to win in practice, but the free should still wait for RCU. Free the link together with its data from a single RCU callback, so the percpu block is reclaimed only after readers drain.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20: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-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-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-68412", "url": "https://ubuntu.com/security/CVE-2026-68412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan() If the test against IEEE80211_MAX_SSID_LEN fails, then 'creq' leaks. Use the existing error handling path to fix it.", "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-64566", "url": "https://ubuntu.com/security/CVE-2026-64566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags() When iptfs_skb_add_frags() copies frag references from the source frag walk into a new SKB, it increments the page reference count via __skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the destination SKB's skb_shinfo->flags. If the source SKB carries shared frags (e.g. from a page-pool backed receive path), the new inner SKB will appear to ESP as having privately owned frags. A subsequent esp_input() call for a nested transport-mode SA then takes the no-COW fast path and decrypts in place, writing over pages that are still referenced by the outer IPTFS SKB. This causes kernel-visible memory corruption and can trigger a panic. All other frag-transfer helpers in the kernel (skb_try_coalesce, skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this convention by setting the flag inside the loop immediately after __skb_frag_ref() and nr_frags++, so every exit path that attaches a frag unconditionally propagates SKBFL_SHARED_FRAG.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68415", "url": "https://ubuntu.com/security/CVE-2026-68415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear mode callbacks after failed mode setup xfrm_state_gc_task can run long after a failed IPTFS state setup. In the reproduced case, __xfrm_init_state() cached x->mode_cbs, IPTFS setup returned -ENOMEM before publishing mode_data, and the temporary module reference from xfrm_get_mode_cbs() was dropped immediately. The dead state then kept x->mode_cbs until deferred GC ran after xfrm_iptfs had been unloaded. Clear x->mode_cbs when mode init or clone fails before publishing mode_data. Those states never installed mode-specific state or the long-term IPTFS module pin, so deferred GC has nothing mode-specific to destroy and must not retain a callback table pointer past the temporary lookup reference. The buggy scenario involves two paths, with each column showing the order within that path: failed setup path: 1. cache x->mode_cbs 2. mode setup fails before mode_data 3. drop the temporary module ref 4. dead state keeps x->mode_cbs cached GC/unload path: 1. xfrm_state_put() queues GC work 2. xfrm_iptfs unloads later 3. xfrm_state_gc_task runs 4. GC dereferences stale x->mode_cbs This also covers the failed clone path where clone_state() returns before publishing mode_data. Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y failslab_stacktrace_filter matched xfrm_iptfs frames ack_error=-12 FAULT_INJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrm_state_gc_task RIP: xfrm_state_gc_task+0x142/0x650 Modules linked in: esp4_offload xfrm_user [last unloaded: xfrm_iptfs] Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68418", "url": "https://ubuntu.com/security/CVE-2026-68418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent user-triggered null deref on QP create Previously, the user QP creation path would only attempt to populate iwqp->iwpbl if the user-provided req.user_wqe_bufs field was non-zero. The problem is that iwqp->iwpbl is unconditionally dereferenced later on in irdma_setup_virt_qp. While there was a check for iwqp->iwpbl != NULL, this check would only occur if req.user_wqe_bufs was non-zero. The end result is that a user could send a zero user_wqe_bufs value and trigger a null ptr deref. Fix this by unconditionally calling irdma_get_pbl and bailing if it fails, similar to the CQ and SRQ paths.", "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-68420", "url": "https://ubuntu.com/security/CVE-2026-68420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: reject optional IPTFS templates in outbound policies syzbot reported a stack-out-of-bounds read in xfrm_state_find() which flows from xfrm_tmpl_resolve_one(). Commit 3d776e31c841 (\"xfrm: Reject optional tunnel/BEET mode templates in outbound policies\") disallowed optional tunnel and BEET in outbound policies to prevent this. Later when IPTFS added, it was not covered by that fix and can still trigger the out-of-bounds read; Extend the check to disallow optional IPTFS in outbound policies as well. IPTFS should be identical to tunnel mode. IN and FWD policies are not affected: xfrm_tmpl_resolve_one() is only reachable via the outbound path. Reproducer, before: ip link add dummy0 type dummy ip link set dummy0 up ip addr add 10.1.1.1/24 dev dummy0 ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 mode transport ping -W 1 -c 1 10.1.1.2 PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data. [ 64.168420] ================================================================== [ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844 [ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full) [ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 64.169977] Call Trace: [ 64.169977] [ 64.169977] dump_stack_lvl+0x47/0x70 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] print_report+0x152/0x4b0 [ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0 [ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20 [ 64.169977] ? __virt_addr_valid+0x21b/0x230 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] kasan_report+0xa8/0xd0 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm_dst_hash+0x24/0xc0 [ 64.169977] xfrm_state_find+0xa2d/0x2f90 [ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570 [ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10 [ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 64.169977] ? kernel_text_address+0x5b/0x80 [ 64.169977] ? __kernel_text_address+0xe/0x30 [ 64.169977] ? unwind_get_return_address+0x5e/0x90 [ 64.169977] ? arch_stack_walk+0x8c/0xe0 [ 64.169977] xfrm_tmpl_resolve+0x130/0x200 [ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10 [ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110 [ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10 [ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310 [ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80 [ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10 [ 64.169977] ? ip_route_output_key_hash+0xc6/0x110 [ 64.169977] ? kasan_save_track+0x10/0x30 [ 64.169977] xfrm_lookup_route+0x18/0xe0 [ 64.169977] ip4_datagram_release_cb+0x4c9/0x530 [ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10 [ 64.169977] ? do_raw_spin_lock+0x71/0xc0 [ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 64.169977] release_sock+0xb0/0x170 [ 64.169977] udp_connect+0x43/0x50 [ 64.169977] __sys_connect+0xa6/0x100 [ 64.169977] ? alloc_fd+0x2e9/0x300 [ 64.169977] ? __pfx___sys_connect+0x10/0x10 [ 64.169977] ? preempt_latency ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68421", "url": "https://ubuntu.com/security/CVE-2026-68421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx() put_prev_task_scx() warns when a runnable task drops to a lower sched_class without SCX_OPS_ENQ_LAST, on the assumption that balance_one() would have kept it running. Core scheduling breaks that: a forced-idle SMT sibling reschedules through the core_pick fast path in pick_next_task(), which skips pick_task_scx() and thus balance_one(), so a runnable task can drop to idle with ENQ_LAST unset. Gate the warning on sched_cpu_cookie_match(): a cookie mismatch means core scheduling forced the idle, while a match (or core scheduling off) still catches a genuine missing-ENQ_LAST drop.", "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-68426", "url": "https://ubuntu.com/security/CVE-2026-68426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix stale skb->prev after async crypto steals a GSO segment skb_gso_segment() leaves the segment list head with ->prev pointing at the last segment, an invariant validate_xmit_skb_list() relies on when it sets its tail pointer (tail = skb->prev). When validate_xmit_xfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validate_xmit_skb_list() later does tail->next = skb, writing through that stale pointer -- a use-after-free. Repoint skb->prev at the last retained segment before returning.", "cve_priority": "critical", "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-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-2023-20585", "url": "https://ubuntu.com/security/CVE-2023-20585", "cve_description": "Insufficient checks of the RMP on host buffer access in IOMMU may allow an attacker with privileges and a compromised hypervisor to trigger an out of bounds condition without RMP checks, resulting in a potential loss of confidential guest integrity.", "cve_priority": "low", "cve_public_date": "2026-04-16 19:16:00 UTC" }, { "cve": "CVE-2026-68364", "url": "https://ubuntu.com/security/CVE-2026-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix ISM dc_lock deadlock during suspend [Why] System hang observed during suspend/resume while video is playing. amdgpu_dm_ism_disable() is called under dc_lock and waits for ISM delayed work via disable_delayed_work_sync(). The work handlers themselves take dc_lock, producing an ABBA deadlock when a worker is in flight at suspend time. [How] Split the disable path into two phases with opposite locking contracts: 1. amdgpu_dm_ism_disable() -- quiesces workers, must NOT hold dc_lock. 2. amdgpu_dm_ism_force_full_power() (new) -- drives the ISM FSM back to FULL_POWER_RUNNING, must hold dc_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72064", "url": "https://ubuntu.com/security/CVE-2026-72064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Sync page pool RX frags for CPU MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack.", "cve_priority": "medium", "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-72098", "url": "https://ubuntu.com/security/CVE-2026-72098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: fix buffer overflow in FEC calculation There's a buffer overflow in dm-verity-fec: if (neras && *neras <= v->fec->roots) \tfio->erasures[(*neras)++] = i; This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72248", "url": "https://ubuntu.com/security/CVE-2026-72248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: support IPIP tunnel with direct xmit The combination of IPIP tunnel with direct xmit, eg. bridge device, breaks because no dst_entry is provided to check the skb headroom and to set the iph->frag_off field. This leads to invalid dst usage and can trigger a crash in the tunnel transmit path. Fix this by moving dst_cache and dst_cookie out of the runtime union so that they can be shared by neighbour, xfrm, and direct tunnel flows. For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve route state in these shared fields and release it through the common dst release path. Since dst_entry is now available to the three supported xmit modes and dst_release() already deals with NULL dst, remove the xmit type check in nft_flow_dst_release(). Moreover, skip the check if the dst entry is NULL in nf_flow_dst_check() which is now the case for the direct xmit case. Based on patch from Rein Wei .", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72249", "url": "https://ubuntu.com/security/CVE-2026-72249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: use dst in this direction when pushing IPIP header When pushing the IPIP header, the route of the other direction is used to calculate the headroom, use the route in this direction. Accessing the other tuple to set the IP source and destination is fine because this tuple does not provide such information to avoid storing redundant information. However, this tuple already provides the dst for this direction, this went unnoticed because this bug affects headroom and iph->frag_off only at this stage.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72287", "url": "https://ubuntu.com/security/CVE-2026-72287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the \"normal\" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a \"late\" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72329", "url": "https://ubuntu.com/security/CVE-2026-72329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/liquidio: drop cached VF pci_dev LUT The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST. Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72355", "url": "https://ubuntu.com/security/CVE-2026-72355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix barriering when walking subrequest list Fix the barriering used when walking the subrequest list in retry as there's a possibility of seeing a subreq that's just been added by the application thread.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72412", "url": "https://ubuntu.com/security/CVE-2026-72412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/mm: Fix handling of _PAGE_UNUSED pte bit The _PAGE_UNUSED softbit should not really be lying around. Its sole purpose is to signal to try_to_unmap_one() and try_to_migrate_one() that the page can be discarded instead of being moved / swapped. KVM has no way to know why a page is being unmapped, so it sets the bit on userspace ptes corresponding to unused guest pages every time they get unmapped. KVM has no reasonable way to clear the bit once the page is in use again. While set_ptes() checks and clears the bit, other paths that set new ptes did not. This led to used pages being thrown out as if they were unused, causing guest corruption. Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in set_pte(), i.e. whenever a present pte is getting set. The check in set_ptes() is then redundant and can be removed. Also fix gmap_helper_try_set_pte_unused() to only set the bit if the pte is present; the _PAGE_UNUSED bit is only defined for present ptes and thus should not be set for non-present ptes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72417", "url": "https://ubuntu.com/security/CVE-2026-72417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto() Add sanity check for iph->ihl field in nf_flow_ip4_tunnel_proto() before using it to compute the header size, avoiding out-of-bounds access with malformed IP headers. While at it, use iph->protocol instead of the hardcoded IPPROTO_IPIP constant when setting ctx->tun.proto and reference ctx->tun.hdr_size when updating ctx->offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72442", "url": "https://ubuntu.com/security/CVE-2026-72442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: fix and simplify IP6IP6 tunnel handling Fix nf_flow_ip6_tunnel_proto() to use pskb_may_pull() instead of skb_header_pointer() to ensure the outer IPv6 header is in the skb headroom, which is required for subsequent packet processing. Move ctx->offset update inside the IPPROTO_IPV6 conditional block since it should only be adjusted when an IP6IP6 tunnel is actually detected. Simplify the rx path by removing ipv6_skip_exthdr() and checking ip6h->nexthdr directly, as the flowtable fast path only handles simple IP6IP6 encapsulation without extension headers. Drop the tunnel encapsulation limit destination option support from the tx path to match, since the rx path no longer handles extension headers. Remove the encap_limit parameter from nf_flow_offload_ipv6_forward(), nf_flow_tunnel_ip6ip6_push() and nf_flow_tunnel_v6_push(), along with the ipv6_tel_txoption struct and related headroom/MTU adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72463", "url": "https://ubuntu.com/security/CVE-2026-72463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix dev use-after-free in xfrm async resumption xfrm async resumption hold skb->dev refcnt until after transport_finish. However, xfrm_rcv_cb may modify skb->dev to tunnel dev without taking device reference, such as vti_rcv_cb. The subsequent async resumption will decrement the tunnel device's reference count, which lead to uaf of tunnel dev and refcnt leak of orig dev as below: unregister_netdevice: waiting for vti1 to become free. Usage count = -2 Stash the original skb->dev to fix refcnt imbalance. The new skb->dev set by xfrm_rcv_cb can race with device teardown. Extend rcu protection over xfrm_rcv_cb and transport_finish to prevent races.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72477", "url": "https://ubuntu.com/security/CVE-2026-72477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: call _ntfs_bad_inode() when failing to rename It is safe to call _ntfs_bad_inode on live inodes since: commit 519b078998ce (\"fs/ntfs3: Exclude call make_bad_inode for live nodes.\") The WARN_ON was added when it wasn't safe by: commit d99208b91933 (\"fs/ntfs3: cancle set bad inode after removing name fails\") Replace the WARN_ON with a call to _ntfs_bad_inode() to prevent further operations on the inconsistent inode.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72493", "url": "https://ubuntu.com/security/CVE-2026-72493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: serialize netif_running() check in enqueue_to_backlog() Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup(). The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit). Commit e9e4dd3267d0 (\"net: do not process device backlog during unregistration\") introduced a lockless netif_running() check in enqueue_to_backlog() to prevent queuing packets to an unregistering device. However, this creates a TOCTOU race window. A lockless transmitter (like veth_xmit) can pass the check before dev_close() clears IFF_UP. If the transmitter is then delayed, flush_all_backlogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed. Fix this by moving the netif_running() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netif_running() after the flush/close completes (so it gets dropped).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72494", "url": "https://ubuntu.com/security/CVE-2026-72494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Replace waitqueue and flag with completion The driver previously used a waitqueue along with an explicit request_done flag, but without proper barriers around request_done. An earlier patch by Gui-Dong Han attempted to fix this by adding the missing memory barriers. Rather than adding the barriers, this patch replaces the waitqueue+flag with a completion, which is designed for this exact purpose.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72496", "url": "https://ubuntu.com/security/CVE-2026-72496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Proper rollback if the ioremap fails bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74269", "url": "https://ubuntu.com/security/CVE-2026-74269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt: fix head underflow on XDP head-grow The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free. The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with this commit applied causes the test to run successfully to completion. The other rx_skb_func implementations don't have this issue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74350", "url": "https://ubuntu.com/security/CVE-2026-74350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate fast symlink target during inode read ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment. A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer. Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated. This keeps malformed fast symlinks from reaching the read path. Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x19f/0x330 (?:?) kasan_report+0xe0/0x110 (?:?) kasan_check_range+0x105/0x1b0 (?:?) __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72495", "url": "https://ubuntu.com/security/CVE-2026-72495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid repeated requests to allocate WC pages Applications can request multiple WC pages for the same ucontext. As of now, only 1 WC page per ucontext is supported. Add a lock to avoid concurrent access and a check to fail repeated requests. Also, if the mmap entry insert fails for the WC, free the Doorbell page index mapped for the WC page.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72501", "url": "https://ubuntu.com/security/CVE-2026-72501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Initialize dpi variable to zero dpi is initialized only for BNXT_RE_ALLOC_WC_PAGE, but copied for all the cases. So initialize the dpi to 0.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72278", "url": "https://ubuntu.com/security/CVE-2026-72278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Re-translate VNCR before injecting abort KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor updates and MMU faults.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68083", "url": "https://ubuntu.com/security/CVE-2026-68083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix path resolution in ksmbd_vfs_kern_path_create The SMB2 open lookup is rooted at the share with LOOKUP_BENEATH, but the create/mkdir/hardlink sink is not: ksmbd_vfs_kern_path_create() builds an absolute path with convert_to_unix_name() and resolves it from AT_FDCWD via start_creating_path(), so a \"..\" component is walked from the real filesystem root and escapes the export. An authenticated client races a missing path component so the rooted open lookup returns -ENOENT (taking the create branch) while the same component is present (a directory) when the create walk runs; the create then resolves \"..\" out of the share. Root the create walk at the share like the lookup and rename paths already are: resolve the parent with vfs_path_parent_lookup(..., LOOKUP_BENEATH, &share_conf->vfs_path) and create the final component with start_creating_noperm(). convert_to_unix_name() then has no callers and is removed.", "cve_priority": "high", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-68457", "url": "https://ubuntu.com/security/CVE-2026-68457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use opener credentials for FSCTL mutations SET_SPARSE, SET_ZERO_DATA and SET_COMPRESSION operate on an open SMB handle but call VFS xattr, fallocate or fileattr helpers with the current ksmbd worker credentials. Those helpers can revalidate inode permissions, ownership and LSM policy independently of the SMB handle access mask. Run each operation with the credentials captured in the target file when the handle was opened. Keep credential handling local to these single-file FSCTLs rather than applying session credentials to the complete IOCTL handler, which also contains handle-less and multi-handle operations.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72041", "url": "https://ubuntu.com/security/CVE-2026-72041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: use sk_msg_free_partial to fix partial send sk_msg_free_partial() ensures consistency of the skmsg at every iteration, without having to manually handle uncharges and offsets. This simplifies the code, and fixes some bugs in skmsg accounting when we don't send the full contents.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72046", "url": "https://ubuntu.com/security/CVE-2026-72046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing.", "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-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21: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-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72137", "url": "https://ubuntu.com/security/CVE-2026-72137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: nat_keepalive: avoid double free on send error nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6 send helper reports an error. That cleanup is only correct before the skb is handed to the output path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the networking stack may already have consumed the skb before returning an error, so freeing it again is unsafe. Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4() and nat_keepalive_send_ipv6(), where the caller still owns the skb, and keep nat_keepalive_send() responsible only for family dispatch and the unsupported-family cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72139", "url": "https://ubuntu.com/security/CVE-2026-72139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: defer md5sig_info kfree past RCU grace period in tcp_connect The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: \tif (needs_md5) { \t\ttcp_ao_destroy_sock(sk, false); \t} else if (needs_ao) { \t\ttcp_clear_md5_list(sk); \t\tkfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); \t} Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with tcp-diag]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72191", "url": "https://ubuntu.com/security/CVE-2026-72191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: validate split-point offset in indx_insert_into_buffer indx_insert_into_buffer() computes used = used1 - to_copy - sp_size; memmove(de_t, Add2Ptr(sp, sp_size), used - le32_to_cpu(hdr1->de_off)); where sp and sp_size come from hdr_find_split(). hdr_find_split() walks entries by le16_to_cpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFS_DE). index_hdr_check(), the on-load gatekeeper, only validates header-level fields (used, total, de_off) and does not walk per-entry sizes. A crafted NTFS image whose leaf INDEX_HDR reports used == total but contains one interior NTFS_DE with size = 0xFFF0 therefore passes validation, descends to indx_insert_into_buffer() through the ntfs_create() -> indx_insert_entry() path, and makes hdr_find_split() return an sp whose sp_size (0xFFF0) greatly exceeds the remaining bytes in the buffer. The u32 subtraction underflows and the memmove count becomes a near-4-GiB value, producing an out-of-bounds kernel write that corrupts adjacent allocations and panics the kernel. Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a single 'touch' inside the mounted directory; crash site resolves to fs/ntfs3/index.c at the memmove. Trigger requires only local mount of an attacker-supplied filesystem image (USB, loopback, or removable media auto-mount). Reject the split whenever the chosen sp plus its declared size already extends past hdr1->used. This is the minimal fix; it preserves the existing hdr_find_split() contract and relies on the same out: cleanup path as the pre-existing error returns. A prior OOB read in the very same indx_insert_into_buffer() memmove was fixed in commit b8c44949044e (\"fs/ntfs3: Fix OOB read in indx_insert_into_buffer\") by tightening hdr_find_e(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdr_find_split(), not hdr_find_e(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72217", "url": "https://ubuntu.com/security/CVE-2026-72217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing xdr_buf_to_bvec() writes a bio_vec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it. rq_bvec, the array passed by nfsd_vfs_write(), is allocated to exactly rq_maxpages entries with no slack. The OOB store can land in adjacent slab memory; the bv_len and bv_offset fields written there are derived from client-supplied RPC payload sizes. Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72220", "url": "https://ubuntu.com/security/CVE-2026-72220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp->rq_procinfo->pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72221", "url": "https://ubuntu.com/security/CVE-2026-72221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: wait for in-flight TLS handshake callback when cancel loses race When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed. The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result. If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue. If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed. Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed to fire because handshake_complete() invokes svc_tcp_handshake_done() unconditionally once it has set HANDSHAKE_F_REQ_COMPLETED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72222", "url": "https://ubuntu.com/security/CVE-2026-72222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: pin svc_xprt across the asynchronous TLS handshake callback svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of(). Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done. The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry. Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all(). [cel: rewrote commit message to describe the actual change]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72277", "url": "https://ubuntu.com/security/CVE-2026-72277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the simpler thing for now and just reject everything that isn't memory.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72279", "url": "https://ubuntu.com/security/CVE-2026-72279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR KVM currently maps the L1 VNCR into the host stage-1 by relying entirely on the permissions of the guest stage-1. At the same time, it is entirely possible that the backing PFN is read-only (e.g. RO memslot), meaning that the L1 VNCR should use at most a read-only mapping. Cache the writability of the PFN in the VNCR TLB and use it to constrain the resulting fixmap permissions. Promote VNCR permission faults to an SEA in the case where the guest attempts to write to a read-only endpoint. Conveniently, this also plugs a page leak found by Sashiko [*] resulting from the early return for a read-only PFN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72288", "url": "https://ubuntu.com/security/CVE-2026-72288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling Hyunwoo Kim reports some really bad races should the following situation occur: - LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C If the last two race nicely enough, vgic_prune_ap_list() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows. The fix is two-fold: - Before dropping the irq and ap_list locks, take a reference on the irq - Do not try to handle migration of the pending bit: there is no expectation that this state is retained, as per the architecture With that, we're sure that the interrupt is still around, and we safely remove it from the AP list as it has no target at this stage (unless another interrupt fires, but that's another story).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "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-72317", "url": "https://ubuntu.com/security/CVE-2026-72317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: pin upper rpc_clnt across the TLS connect_worker The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt. The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported. Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one. The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72318", "url": "https://ubuntu.com/security/CVE-2026-72318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate DFS referral string offsets parse_dfs_referrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server. Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative max_len is then passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds. Validate each string offset before deriving the string pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72320", "url": "https://ubuntu.com/security/CVE-2026-72320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_lookup: fix catchall element handling with inverted lookups nft_lookup_eval() decides whether a lookup matched (`found`) from the direct set lookup and priv->invert before falling back to the catchall element used by interval sets (e.g. nft_set_rbtree) for the open-ended default range. Since `found` is never recomputed after `ext` is replaced by the catchall lookup, inverted lookups (NFT_LOOKUP_F_INV, \"!= @set\") can wrongly match or wrongly skip the catchall element, producing the wrong verdict. Fold the catchall lookup into `ext` before computing `found`, matching the order already used by nft_objref_map_eval().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72366", "url": "https://ubuntu.com/security/CVE-2026-72366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_create_write_req() to handle async cache object creation netfs_create_write_req() will skip caching if the fscache cookie is disabled, but this is a problem because async cache object creation might not have got far enough yet that has been enabled - thereby causing the call to fscache_begin_write_operation() to be skipped. Fix this by removing the checks on the cookie and delegating this to fscache_begin_write_operation().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72381", "url": "https://ubuntu.com/security/CVE-2026-72381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of fp->owner.name in durable handle owner check Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d (\"ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd\") made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized. BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8 Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72393", "url": "https://ubuntu.com/security/CVE-2026-72393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: don't cache shinfo across skb realloc fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb including the shared info. We can't use the pointer calculated before the call. BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0 Read of size 4 at addr ff110000262edd98 by task swapper/5/0 Call Trace: fbnic_tx_lso.isra.0+0x668/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 Allocated by task 8653: __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xcc/0x6c0 sock_alloc_send_pskb+0x327/0x3f0 __ip_append_data+0x188b/0x47a0 ip_make_skb+0x24a/0x300 udp_sendmsg+0x14d2/0x21e0 Freed by task 0: kfree+0x123/0x5a0 pskb_expand_head+0x36c/0xfa0 fbnic_tx_lso.isra.0+0x500/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 sch_direct_xmit+0x25b/0x1100 The buggy address belongs to the object at ff110000262edc40 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 344 bytes inside of freed 640-byte region [ff110000262edc40, ff110000262ede", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72398", "url": "https://ubuntu.com/security/CVE-2026-72398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: add INIT verification after cookie unpacking In SCTP handshake, the INIT chunk is initially processed by the server and embedded into the cookie carried in INIT-ACK. The client then returns this cookie via COOKIE-ECHO, where the server unpacks it and reconstructs the original INIT chunk. When cookie authentication is enabled, the cookie contents are protected against tampering, so reusing the unpacked INIT without re-verification is safe. However, when cookie authentication is disabled, the reconstructed INIT can no longer be trusted. In this case, the INIT must be explicitly validated after unpacking to avoid processing potentially tampered data. Add sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO processing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook()) when cookie_auth_enable is disabled. On failure, the new association is freed and the packet is discarded. Also tighten cookie validation in sctp_unpack_cookie() by verifying the embedded chunk type is SCTP_CID_INIT before treating it as an INIT chunk. Finally, update sctp_verify_init() to validate parameter bounds using the actual embedded INIT length instead of chunk->chunk_end, since the INIT stored in COOKIE-ECHO may not span the entire chunk buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72399", "url": "https://ubuntu.com/security/CVE-2026-72399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: check the number of BDs needed for xdp_frame The size of xdp_redirect_arr array is ENETC_MAX_SKB_FRAGS. However, the number of fragments contained in xdp_frame may be greater than or equal to ENETC_MAX_SKB_FRAGS, which will cause the access to xdp_redirect_arr to be out of bounds.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72429", "url": "https://ubuntu.com/security/CVE-2026-72429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix type confusion of dst_entry IOAM uses a dummy dst_entry(null_dst) to mark that the destination should not be changed after the transformation. This dst is stored in the IOAM lwt state and may be passed to dst_cache_set_ip6(). However, the IPv6 dst cache path eventually calls rt6_get_cookie(), which treats the dst_entry as part of a struct rt6_info. Since the null_dst was embedded directly as a struct dst_entry in struct ioam6_lwt, this resulted in an invalid cast and rt6_get_cookie() reading fields from the wrong object. In practice, the wrong cookie is not used while dst->obsolete is zero, but rt6_get_cookie() may also access per-cpu value when rt->sernum is zero. In this case, rt->sernum aliases ioam6_lwt::cache::reset_ts, which can become zero, making this a potential invalid pointer access. Fix this by embedding a full struct rt6_info for the dummy IPv6 route and passing its dst member to the dst APIs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72436", "url": "https://ubuntu.com/security/CVE-2026-72436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash types Sashiko pointed out that there are a few lockless RCU readers using test_bit() which is a relaxed atomic operation and provides no memory barrier guarantees. Use test_bit_acquire() instead where the operation may run parallel with add/del/gc, i.e. is not one from the next cases - protected by region lock - in a set destroy phase - in a new/temporary set creation phase", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72451", "url": "https://ubuntu.com/security/CVE-2026-72451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix xfrm state cache insertion race The xfrm input state cache insertion code checks the validity of the state before acquiring the global xfrm_state_lock. Thus it's possible for someone else to kill the state after it passed the validity check, and then the insertion will add the dead state to the cache. Fix this by moving the validity check inside the lock. This entire function is called on the input path, where BH must be off (e.g., the caller of this function xfrm_input acquires its spinlocks without disabling BH). So there is no need to disable BH here or take the RCU read lock. Remove both and replace them with an assertion that trips if BH is accidentally enabled on some future calling path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72472", "url": "https://ubuntu.com/security/CVE-2026-72472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: use nfsi->rwsem to protect traversal of the file lock list Lingfeng identified a bug and suggested two solutions, but both appear to have issues. Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case. Furthermore, after commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk. Regarding the bug fixed by commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), it has been resolved after commit 0460253913e5 (\"NFSv4: nfs4_do_open() is incorrectly triggering state recovery\") because all slots are drained before calling nfs4_do_reclaim, which prevents concurrent stateid changes along this path. Also, nfs_delegation_claim_locks does not cause this concurrency either since when _nfs4_proc_setlk is called with NFS_DELEGATED_STATE, no RPC is sent, so nfs4_lock_done is not called. Therefore, nfs4_lock_delegation_recall from nfs_delegation_claim_locks is the first time the stateid is set.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72473", "url": "https://ubuntu.com/security/CVE-2026-72473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decouple req recycling from RPC completion rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer. Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off. The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry. Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied. Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected. Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released. The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74310", "url": "https://ubuntu.com/security/CVE-2026-74310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/net: complete zerocopy ubufs only once vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74345", "url": "https://ubuntu.com/security/CVE-2026-74345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix endpoint/socket association handling Disassociating a socket from an endpoint via siw_socket_disassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within. This fixes a: BUG: KASAN: slab-use-after-free in siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1053 drivers/infiniband/sw/siw/siw_cm.c:1075) which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74361", "url": "https://ubuntu.com/security/CVE-2026-74361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: fix FDP fdpcidx bounds check The fdpcidx bounds check sets n = NUMFDPC + 1 but used > instead of >=, incorrectly accepting fdp_idx when it equals n (i.e. NUMFDPC + 1).", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74401", "url": "https://ubuntu.com/security/CVE-2026-74401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix add msg handle in send_queue ordered In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as \"before(mh->seq, seq)\" will stop to check for older sequence numbers that are ordered in the tail of \"node->send_queue\". The side effects of not having it correct ordered regarding \"before(mh->seq, seq)\" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74406", "url": "https://ubuntu.com/security/CVE-2026-74406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74428", "url": "https://ubuntu.com/security/CVE-2026-74428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix double unlock in rxrpc_recvmsg() Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74433", "url": "https://ubuntu.com/security/CVE-2026-74433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix UAF in rxgk_issue_challenge() Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74434", "url": "https://ubuntu.com/security/CVE-2026-74434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Don't move a peeked OOB message onto the pending queue rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so only unlink it from recvmsg_oobq and then move it onto pending_oobq or free it when the message is actually consumed.", "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-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-74439", "url": "https://ubuntu.com/security/CVE-2026-74439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clear Present bit before tearing down scalable-mode context entry device_pasid_table_teardown() zeroes the 128-bit scalable-mode context entry with context_clear_entry() while the Present bit is still set. This creates a window where the hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behavior or spurious faults. The context-cache invalidation is issued only after the entry has been zeroed, and intel_pasid_free_table() then frees the PASID directory pages, so the IOMMU can keep walking a stale Present=1 entry that points at freed memory. While x86 provides strong write ordering, the compiler may reorder the two 64-bit writes to the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Commit c1e4f1dccbe9d (\"iommu/vt-d: Clear Present bit before tearing down context entry\") fixed this exact pattern in domain_context_clear_one() and the copied-context path, but device_pasid_table_teardown() was not converted. Align it with the \"Guidance to Software for Invalidations\" in the VT-d spec, Section 6.5.3.3, using the same ownership handshake as the sibling fix: clear only the Present bit, flush it to the IOMMU, perform the context-cache invalidation, and only then zero the rest of the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2165483, 2165484, 2165407, 2166547, 2166443, 2166356, 2165872, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165407, 2165040, 2161748, 2163508, 2163214, 2162904, 2162045, 2164967, 2160082, 2164504, 2156316, 2164716, 2164516, 2163375, 2162803, 2163062, 2132119, 2163293, 2160200, 2158858, 2162704, 2162695, 2164666, 2164666, 2163121 ], "changes": [ { "cves": [ { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-68105", "url": "https://ubuntu.com/security/CVE-2026-68105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix kernel panic during driver load failure Avoid kernel panic if MES init fails during driver load. The KIQ ring is falsely marked as ready as ASICs that use MES, KIQ is owned by MES. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] Call Trace: gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280 __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53 (cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68109", "url": "https://ubuntu.com/security/CVE-2026-68109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68114", "url": "https://ubuntu.com/security/CVE-2026-68114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit e4d99e04b2e9b13b97d3b17804c735f62689db23)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68431", "url": "https://ubuntu.com/security/CVE-2026-68431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate minimum PDU size for transform requests The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68138", "url": "https://ubuntu.com/security/CVE-2026-68138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: serialize qdisc_rtab_list against concurrent get/put qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68082", "url": "https://ubuntu.com/security/CVE-2026-68082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix two unsafe bare decodes in decode_lockers() decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-08 10:16:00 UTC" }, { "cve": "CVE-2026-68159", "url": "https://ubuntu.com/security/CVE-2026-68159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68163", "url": "https://ubuntu.com/security/CVE-2026-68163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_vma_mapped: fix device-private PMD handling Commit 65edfda6f3f2 (\"mm/rmap: extend rmap and migration support device-private entries\") introduced the concept of device-private PMD entries, but did not correctly update the rmap walk code to account for them. As a result, when page_vma_mapped_walk() encounters device-private PMD entries, it takes no action other than to acquire the PMD lock and exit. However this is highly problematic for two reasons - firstly, device private entries possess a PFN so check_pmd() needs to be called to ensure an overlapping PFN range. Secondly, and more importantly, if PVMW_MIGRATION is set the caller assumes the returned entry is a migration entry, resulting in memory corruption when the caller tries to interpret the device private entry as such. In addition, commit 146287290023 (\"mm/huge_memory: implement device-private THP splitting\") allowed device private PMDs to be split like THP mappings, but again did not update this code path. As a result, we might race a PMD split prior to acquiring the PMD lock. This patch addresses all of these issues by invoking check_pmd(), ensuring PMVW_MIGRATION is not set and checks whether a split raced us we do for PMD THP and migration entries. Instead of checking for a subset of the cases after taking the pmd_lock(), put device-private along with pmd_trans_huge() and pmd_is_migration_entry(). Also remove thp_migration_supported() as it is already guarded by pmd_is_migration_entry(). [akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68166", "url": "https://ubuntu.com/security/CVE-2026-68166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: prevent registration of special VMAs Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68170", "url": "https://ubuntu.com/security/CVE-2026-68170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix stale skb->sk reference on subflow close The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68177", "url": "https://ubuntu.com/security/CVE-2026-68177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Delay module ref count for \"enable_event\" trigger Triggers are now delayed from freeing, but can still be triggered until after the RCU grace period has ended. The freeing of the enable_event data is put into the private_data_free() callback, but the put of the module refcount is done immediately. It is possible that if a module is removed that has an event that would enable (or disable) it is still active, it can read the data of the module after it is removed causing a use-after-free bug. Move the trace_event_put_ref() that releases the module into the delayed callback so that the module can not be removed until any reference to its events are finished.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68191", "url": "https://ubuntu.com/security/CVE-2026-68191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix NULL pointer dereference in rhash table destroy When unbinding the ath12k driver, kernel NULL pointer dereferences occur in irq_work_sync() called from rhashtable_destroy(). Two hash tables are affected: 1. ath12k_link_sta hash table in ath12k_base 2. ath12k_dp_link_peer hash table in ath12k_dp The issue happens because the destroy functions are called unconditionally in cleanup paths, but the hash tables are only initialized late in their respective init functions. If the device was never fully started or if the init functions failed before initializing the hash tables, the pointers will be NULL. The issues are always reproducible from a VM because the MSI addressing initialization is failing. Call trace for ath12k_link_sta_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_link_sta_rhash_tbl_destroy+0x19/0x40 [ath12k] ath12k_core_stop+0xe/0x80 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Call trace for ath12k_dp_link_peer_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_dp_link_peer_rhash_tbl_destroy+0x29/0x50 [ath12k] ath12k_dp_cmn_device_deinit+0x21/0x140 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Fix this by adding NULL checks before calling rhashtable_destroy() in both destroy functions. The NULL check approach was chosen because the rhashtable pointer serves as the initialization state indicator. The init can fail at various points, leaving some components uninitialized. Checking the pointer directly is simpler than adding separate state flags that would need synchronization.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64586", "url": "https://ubuntu.com/security/CVE-2026-64586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: drain bus_reset work on device removal brcmf_fw_crashed() and the debugfs \"reset\" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs \"reset\" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. 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-68208", "url": "https://ubuntu.com/security/CVE-2026-68208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: Fix the error code of devm_kzalloc() in vip_probe_slice() In vip_probe_slice(), the error check for devm_kzalloc() incorrectly uses PTR_ERR_OR_ZERO() which returns 0 for NULL pointer. Return -ENOMEM for devm_kzalloc() failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68224", "url": "https://ubuntu.com/security/CVE-2026-68224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mali-c55: Fix possible ERR_PTR in enable_streams The media_pad_remote_pad_unique() function returns either a valid pointer or an ERR_PTR() on failure (-ENOTUNIQ if multiple links are enabled, -ENOLINK if no connected pad is found). The return value was assigned directly to isp->remote_src and dereferenced in the next line without checking for errors, which could lead to an ERR_PTR dereference. Add proper error checking with IS_ERR() before dereferencing the pointer. Also set isp->remote_src to NULL on error to maintain consistency with other error paths in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68237", "url": "https://ubuntu.com/security/CVE-2026-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: fix indefinite fence wait during GPU reset pre_reset only force-completes fences of MAPPED queues. A queue in any other state (e.g. mid-eviction) keeps its last_fence pending; after a GPU reset that fence never signals, so the eviction/suspend worker and process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and wedge the machine: INFO: task kworker/6:28 blocked for more than 120 seconds. Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu] Call Trace: dma_fence_wait_timeout+0x7e/0x130 amdgpu_userq_evict+0x67/0x140 [amdgpu] amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu] process_scheduled_works+0xa6/0x420 Force-complete every queue's fence regardless of state. The unmap and mark-hung step stays gated on MAPPED, since unmapping a queue that is not mapped is invalid. (cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68240", "url": "https://ubuntu.com/security/CVE-2026-68240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: publish dpagemap early to avoid device mapping leak on error drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68242", "url": "https://ubuntu.com/security/CVE-2026-68242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix NULL deref on sched_engine alloc failure Avoid using intel_context_put() before intel_context_init() in execlists_create_virtual() as the kref_put() inside would lead to NULL deref on the IOCTL path when sched_engine allocation fails. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68254", "url": "https://ubuntu.com/security/CVE-2026-68254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: require valid min/max vfreq for VRR Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68436", "url": "https://ubuntu.com/security/CVE-2026-68436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use kvzalloc to allocate struct dc struct dc has grown large over time (most of it the two inlined dc_scratch_space copies) and now sits close to the page allocator's 4 MiB contiguous allocation limit. Its actual size is not fixed by the source alone, it also depends on the compiler and the .config, so it can easily cross 4 MiB, e.g. with a newer GCC or a config change. dc_create() allocates it with kzalloc(). Once struct dc exceeds 4 MiB the request is rounded up to order 11 (8 MiB), which is above MAX_PAGE_ORDER, so the page allocator warns and returns NULL. dc_create() then fails, DM init fails and amdgpu probe aborts with -EINVAL: WARNING: mm/page_alloc.c:5197 at __alloc_frozen_pages_noprof+0x2f9/0x380 dc_create+0x38/0x660 [amdgpu] amdgpu_dm_init+0x2d9/0x510 [amdgpu] dm_hw_init+0x1b/0x90 [amdgpu] amdgpu_device_init.cold+0x150d/0x1e13 [amdgpu] amdgpu_driver_load_kms+0x19/0x80 [amdgpu] amdgpu_pci_probe+0x1e2/0x4c0 [amdgpu] dc_create() then returns NULL and DM init fails, which aborts the whole GPU init and makes amdgpu probe fail with -EINVAL (\"hw_init of IP block failed -22\"), leaving the display unusable. The subsequent amdgpu_irq_put() warnings during teardown are just fallout of unwinding a half-initialized device. struct dc is a software-only bookkeeping structure that is never handed to hardware DMA and is only ever kept as an opaque pointer, so it does not require physically contiguous memory. Allocate it with kvzalloc() (and free it with kvfree()) so that the allocator can fall back to vmalloc() when a contiguous allocation of that size is not available, which also avoids the MAX_PAGE_ORDER warning entirely. v2: - Rebase to amd-staging-drm-next. (cherry picked from commit 991e0516a8072f2292681c6ae98a924ab0e32575)", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68447", "url": "https://ubuntu.com/security/CVE-2026-68447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size from hardware without bounding it to the allocated BO region. If the HW field is larger than the queue's control stack allocation, memcpy reads past the BO into adjacent GTT memory and can leak kernel data to userspace. Store the page-aligned control stack BO size in mqd_manager and clamp checkpoint copies and reported checkpoint sizes to min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound for multi-XCC v9.4.3 checkpoint layout. (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3)", "cve_priority": "high", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68264", "url": "https://ubuntu.com/security/CVE-2026-68264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: Reset current_op in xe_pt_update_ops_init() xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it. After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind. Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry. Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(). v2 (Matt): - Add details in commit message. - Add Fixes tag and Cc to stable@vger.kernel.org (cherry picked from commit 046045543e530605c441063535e7dca0075369a6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68265", "url": "https://ubuntu.com/security/CVE-2026-68265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO's tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference (cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68267", "url": "https://ubuntu.com/security/CVE-2026-68267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists Unconditionally whitelisting OA registers is a security violation. Set RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers don't get whitelisted by default after probe, gt reset, resume and engine reset. (cherry picked from commit 90511bdcfda97211c01f1d945d4ea616578d8fca)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68273", "url": "https://ubuntu.com/security/CVE-2026-68273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68274", "url": "https://ubuntu.com/security/CVE-2026-68274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix buffer overflow in steered register list allocation The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt->fuse_topo.g_dss_mask, ...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68283", "url": "https://ubuntu.com/security/CVE-2026-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free freeing trigger private data Commit 61d445af0a7c (\"tracing: Add bulk garbage collection of freeing event_trigger_data\") moved the kfree() of event_trigger_data to a kthread that runs tracepoint_synchronize_unregister() before freeing. That removed the synchronization the trigger .free callbacks used to get implicitly and inline from trigger_data_free(). event_hist_trigger_free(), event_hist_trigger_named_free() and event_enable_trigger_free() free their satellite data (hist_data, cmd_ops, enable_data) right after trigger_data_free() returns. With the synchronization now deferred to the kthread, a concurrent tracepoint handler can still reach that data through the list_del_rcu()'d trigger, causing a use-after-free. The histogram teardown must stay synchronous: remove_hist_vars() and unregister_field_var_hists() have to detach a synthetic event from the histogram before the trigger-removal write returns, otherwise a following command races in and the synthetic-event removal fails with -EBUSY, as the trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait with the correct barrier - tracepoint_synchronize_unregister(), matching the free kthread - before freeing. The enable trigger has no such synchronous requirement, and a blocking synchronize there would re-serialize the path that commit deliberately deferred. Give it an optional private_data_free() callback that the free kthread runs after its grace period, and free enable_data from there.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68286", "url": "https://ubuntu.com/security/CVE-2026-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68287", "url": "https://ubuntu.com/security/CVE-2026-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix size calculations for 64-bit attributes net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68288", "url": "https://ubuntu.com/security/CVE-2026-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68289", "url": "https://ubuntu.com/security/CVE-2026-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68291", "url": "https://ubuntu.com/security/CVE-2026-68291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix max_vport related crash on allocation error during init Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000 [ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000 [ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20 [ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000 [ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0 [ 320.417385] PKRU: 55555554 [ 320.417398] Call Trace: [ 320.417412] [ 320.417429] pci_device_remove+0x42/0xb0 [ 320.417459] device_release_driver_internal+0x1a9/0x210 [ 320.417492] driver_detach+0x4b/0x90 [ 320.417516] bus_remove_driver+0x70/0x100 [ 320.417539] pci_unregister_driver+0x2e/0xb0 [ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0 [ 320.417592] ? kmem_cache_free+0x31e/0x550 [ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190 [ 320.417644] ? do_syscall_64+0x38/0x6b0 [ 320.417665] do_syscall_64+0xc8/0x6b0 [ 320.417683] ? clear_bhb_loop+0x30/0x80 [ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 320.417727] RIP: 0033:0x7f963bb30beb", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68303", "url": "https://ubuntu.com/security/CVE-2026-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hvs/v3d: Fix null dereference in unbind The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68312", "url": "https://ubuntu.com/security/CVE-2026-68312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and cifs_close_deferred_file_under_dentry(), when a pending deferred close is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to add the file to the local processing list may fail under memory pressure. The loop breaks immediately, but the cancelled work is no longer pending (it would have called _cifsFileInfo_put()), and the cfile is never added to file_head for processing. The cifsFileInfo reference and the open server handle both leak. Fix by saving the cfile that failed allocation in a local variable, breaking as before, and calling _cifsFileInfo_put() on it after releasing the lock. Any files later in the iteration are unaffected since their deferred work is still pending and will fire normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68316", "url": "https://ubuntu.com/security/CVE-2026-68316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Fix element size accounting for cmd stream validation There are 2 issues with the element size handling in the command stream validation which result in too small of a size calculated when the element size is 16/32/64 bits. For NHWC format, the element size is simply missing from the calculation. The bitfield for the element size is different between IFM/IFM2 and OFM. IFM and IFM2 encode the precision in parameter bits 2:3, while OFM uses bits 1:2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68440", "url": "https://ubuntu.com/security/CVE-2026-68440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix heap overflow when reading module EEPROM txgbe_read_eeprom_hostif() always copies round_up(length, 4) bytes into the caller buffer, which ethtool allocates with exactly 'length' bytes. A non-4-aligned length therefore causes an out-of-bounds write. Copy only the remaining bytes on the final dword instead.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68323", "url": "https://ubuntu.com/security/CVE-2026-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: serialize udp bearer replicast list updates tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68441", "url": "https://ubuntu.com/security/CVE-2026-68441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected. This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d (\"bpf: add bpf_redirect() helper\"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available. commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs. Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a wrapper around tcf_classify() for use by qdisc classify functions and tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT, the wrapper converts it to TC_ACT_SHOT, dropping the packet rather than letting it continue silently. Dropping is preferred over letting the packet through because the user immediately sees packet loss. Silently passing the packet through would hide the problem and leave the user wondering why their redirect is not working. The clsact fast path, tc_run() continues to call tcf_classify() directly and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by sch_handle_egress/ingress() calling skb_do_redirect() as before.", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68337", "url": "https://ubuntu.com/security/CVE-2026-68337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject redirect helpers without a bpf_net_context The bpf_redirect*() helpers and skb_do_redirect() obtain the per-task bpf_redirect_info via bpf_net_ctx_get_ri(), which dereferences the current->bpf_net_context unconditionally. That context is established on the paths that run tc BPF such as sch_handle_{ingress,egress}(), *except* for the case where {cls,act}_bpf was attached to a proper qdisc. A program running from there reaches the NULL deref in two ways: * It calls bpf_redirect() directly, which dereferences the context at the top of the helper: tc qdisc add dev eth0 root handle 1: red limit 1MB min 10KB max 20KB \\ avpkt 1000 burst 100 qevent early_drop block 10 tc filter add block 10 pref 1 bpf obj redirect.o * It simply returns TC_ACT_REDIRECT without helper call: tcf_qevent_handle() then dispatches to skb_do_redirect(), which dereferences the context Rather than extending bpf_net_context management into the qdisc path, make the redirect helpers refuse to operate when no context exists, and have tcf_qevent_handle() drop a TC_ACT_REDIRECT verdict instead of calling skb_do_redirect(). Previous behaviour was a crash, so nothing regresses by not supporting it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68345", "url": "https://ubuntu.com/security/CVE-2026-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm_mpam: guard MBWU state before adding it to garbage __destroy_component_cfg() adds each RIS mbwu_state object to the MPAM garbage list when destroying component configuration. However, mbwu_state is allocated per RIS and only for RISes with MBWU monitors. A component can therefore have comp->cfg allocated while some RISes still have ris->mbwu_state set to NULL. Passing a NULL mbwu_state to add_to_garbage() dereferences the NULL pointer inside the macro. Skip RISes that do not have an mbwu_state object before adding them to the garbage list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68347", "url": "https://ubuntu.com/security/CVE-2026-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68375", "url": "https://ubuntu.com/security/CVE-2026-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle partially initialized auxiliary devices bnxt_aux_devices_init() calls auxiliary_device_init() before all fields used by bnxt_aux_dev_release() are initialized. After auxiliary_device_init() succeeds, later errors must unwind with auxiliary_device_uninit(), which invokes the release callback. The release callback assumes that aux_priv->id, aux_priv->edev, edev->net and edev->ulp_tbl are all populated. If allocation fails after auxiliary_device_init(), the release path can otherwise dereference or clear partially initialized state. Allocate and attach the bnxt_en_dev and ULP table before calling auxiliary_device_init(), so the release callback only sees a fully initialized auxiliary private object. If auxiliary_device_init() itself fails, free those allocations directly because device_initialize() has not run and the release callback will not be invoked. 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-68382", "url": "https://ubuntu.com/security/CVE-2026-68382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Hold device ref until queue teardown completes GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock. Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending. Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work. With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. Replace the fini wait with an assertion and remove the unused fini_wq. v2: - Rebase v3: - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt) - Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt) - Drop separate deferred drm_dev_put worker. - Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini(). v4: - Replace the guc_submit_sw_fini() wait with an assertion and remove the now-unused fini_wq. (sashiko) v5: - Move destroy work to a module-lifetime Xe workqueue instead of system_dfl_wq. (Matt) - Flush the module-lifetime destroy workqueue during PCI remove to preserve the old device-remove wait semantics. v6: - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid letting it outlive the xe_device/drm_device. (Sashiko) - Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work can be queued from the reclaim path. v7: - Drop the per-device xe->destroy_wq and use the module-level destroy WQ for SVM pagemap destroy as well. (Matt) - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*() helpers because the WQ is no longer exec-queue specific. (Matt) v8: - Rebase. v9: - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM destroy_wq because it can be queued from reclaim and embeds the dev_pagemap used by devres teardown. (Sashiko) - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM from it. - Update the module-WQ kdoc to document the GuC/SVM split. v10: - Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the workqueue allocation warning. v11: - Drop the SVM pagemap destroy comment as it was revision-specific. (Thomas) v12: - Rebase. (cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68383", "url": "https://ubuntu.com/security/CVE-2026-68383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Keep scheduler timeline name alive The scheduler keeps a pointer to the timeline name, but q->name is freed with the exec queue while scheduler fences can still reference it. Store the name in struct xe_guc_exec_queue so it shares the scheduler's RCU-deferred lifetime. (cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68390", "url": "https://ubuntu.com/security/CVE-2026-68390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups hci_conn_params_lookup requires hdev->lock be held, otherwise the list iteration or param access is not safe. Hold hdev->lock for params lookups in hci_sync.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-2026-68404", "url": "https://ubuntu.com/security/CVE-2026-68404", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: use wiphy work for socket owner autodisconnect nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68367", "url": "https://ubuntu.com/security/CVE-2026-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: synchronize delayed set_alt with teardown The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68095", "url": "https://ubuntu.com/security/CVE-2026-68095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse-uring: fix race between registration and connection abortion This fixes this race: - thread a: io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref yet - thread b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() is a no-op due to queue ref being 0 - thread a: grabs the queue_ref, queue_ref is now 1, rest of fuse_uring_do_register() logic executes - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs and calls \"wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);\" The abort/unmount thread will hang indefinitely in unkillable state as nothing will decrement queue_refs or wake stop_waitq, and the ring, queue, and ent are leaked. Fix this by checking fch->connected under fch->lock after the created ent has grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either release the queue ref and wake up stop_waitq (in case fuse_chan_wait_aborted() is already waiting) in fuse_uring_do_register() when we detect !fch->connected, or if the connection is aborted after the check, it is guaranteed that the async teardown worker will be running in the background cleaning up ents and decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-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-68173", "url": "https://ubuntu.com/security/CVE-2026-68173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: wait on ublk_dev_ready() instead of ub->completion ub->completion is only re-armed by a successful START_USER_RECOVERY. If the ublk server sends END_USER_RECOVERY without one - e.g. its START failed with -EBUSY and the error was ignored - the wait is satisfied by the stale completion of the previous recovery cycle, and the device is marked LIVE and the requeue list kicked while the FETCH stream is still running and ubq->canceling is still set. The kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it again via __ublk_abort_rq(), and after the last FETCH clears ->canceling nothing ever kicks the requeue list again: the request is stranded there while holding its tag. If it is the flush machinery's flush_rq, every subsequent fsync piles up in uninterruptible sleep and teardown hangs on tag draining. This matches a report of a lost PREFLUSH with ext4 on top of ublk after daemon crash recovery. ub->completion is an edge-triggered latch used as a proxy for the level condition \"every queue has fetched all I/O commands\", which can regress (F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop it and wait on the real condition instead: the new helper ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then re-checks it under ub->mutex, waiting again on regression, and returns with the mutex held and readiness guaranteed. Readiness becomes true in the same ub->mutex critical section that clears the last queue's ->canceling, so END_USER_RECOVERY marks the device LIVE and kicks the requeue list strictly after ->canceling clears. The wait stays interruptible, so a server whose daemon died can still be signalled out. For ublk_ctrl_start_dev() this replaces the fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting until the device is ready again.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68113", "url": "https://ubuntu.com/security/CVE-2026-68113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68118", "url": "https://ubuntu.com/security/CVE-2026-68118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: challenge ACK for non-exact RST in SYN-RECEIVED The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68120", "url": "https://ubuntu.com/security/CVE-2026-68120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtase: Workaround for TX hang caused by hardware packet parsing The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission.", "cve_priority": "medium", "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-68122", "url": "https://ubuntu.com/security/CVE-2026-68122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix peer refcount leak in TCP error paths When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&peer->tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object. The race window: CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error): ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2 schedule_work() <- queued schedule_work() <- NO-OP (work already pending) ovpn_tcp_peer_del_work runs: ovpn_peer_del() ovpn_peer_put() <- refcnt+1 <- peer never freed Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68128", "url": "https://ubuntu.com/security/CVE-2026-68128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: reject out-of-range ptype in ice_parser_profile_init set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from providing ptype >= 1024 through VIRTCHNL, resulting in a write past the end of the bitmap and a kernel page fault. Reproduced with a custom kernel module injecting a crafted VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1. crash_parser: ice_parser_profile_init @ ffffffffc0d61b60 crash_parser: setting ptype=0xffff (max valid=1023) crash_parser: calling ice_parser_profile_init -- expect OOB crash! BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace: ? __pfx_ice_parser_profile_init+0x10/0x10 [ice] crash_init+0x127/0xff0 [crash_parser] do_one_initcall+0x45/0x310 do_init_module+0x64/0x270 init_module_from_file+0xcc/0xf0 idempotent_init_module+0x17b/0x280 __x64_sys_finit_module+0x6e/0xe0 Bail out early with -EINVAL when ptype is out of range.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68132", "url": "https://ubuntu.com/security/CVE-2026-68132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: super: fix emergency thaw deadlock on frozen block devices do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68133", "url": "https://ubuntu.com/security/CVE-2026-68133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP Call Trace during PTP release If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will result in the following PTP release call trace during driver unload: kernel BUG at lib/list_debug.c:52! ice_ptp_release+0x332/0x3c0 [ice] ice_deinit_features.part.0+0x10e/0x120 [ice] ice_remove+0x100/0x220 [ice] This was observed when passing PF1 through to a VM. ice_ptp_init() fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT. Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and returning without error, preventing the invalid state transition to ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from ICE_PTP_RESETTING after a failed rebuild.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68134", "url": "https://ubuntu.com/security/CVE-2026-68134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: ptp_s390: Add missing facility check Only register the physical clock when facility 28 is installed and PTFF QAF returns that PTFF QPT is available.", "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-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-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-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-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-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-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-68150", "url": "https://ubuntu.com/security/CVE-2026-68150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/super: fix emergency thaw double-unlock of s_umount do_thaw_all() iterates over all superblocks via __iterate_supers() with SUPER_ITER_EXCL, which acquires s_umount exclusively before calling the callback and releases it afterwards. However, the callback do_thaw_all_callback() calls thaw_super_locked() which unconditionally releases s_umount on every code path. This results in a second unlock attempt in __iterate_supers() that corrupts the rwsem state, triggering a DEBUG_RWSEMS warning: [ 182.601148] sysrq: Emergency Thaw of all frozen filesystems [ 182.601865] ------------[ cut here ]------------ [ 182.602375] DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff99b1011e5870, owner = 0x0, curr 0xffff99b101b06c80, list not empty [ 182.603817] WARNING: kernel/locking/rwsem.c:1412 at up_write+0xa3/0x170, CPU#2: kworker/2:1/53 [ 182.604578] Modules linked in: [ 182.604864] CPU: 2 UID: 0 PID: 53 Comm: kworker/2:1 Not tainted 7.2.0-rc4-00001-gbd3bd93ea98a-dirty #4 PREEMPT(lazy) [ 182.605711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014 [ 182.606417] Workqueue: events do_thaw_all [ 182.606750] RIP: 0010:up_write+0xaf/0x170 [ 182.607076] Code: 19 3a 92 48 0f 44 c2 48 8b 55 08 48 8b 55 00 4c 8b 45 08 48 8b 55 00 48 8d 3d ad 91 e0 01 48 8b 4d 20 50 48 c7 c6 f0 8c 26 92 <67> 48 0f b9 3a e8 d7 93 4e 00 58 eb 81 48 83 7f 18 00 48 c7 c2 8d [ 182.608563] RSP: 0018:ffffb670001d7e08 EFLAGS: 00010246 [ 182.609007] RAX: ffffffff92349e8d RBX: 0000000000000000 RCX: ffff99b1011e5870 [ 182.609595] RDX: 0000000000000000 RSI: ffffffff92268cf0 RDI: ffffffff92914d10 [ 182.610283] RBP: ffff99b1011e5870 R08: 0000000000000000 R09: ffff99b101b06c80 [ 182.610847] R10: ffff99b10139a808 R11: fefefefefefefeff R12: 0000000000000000 [ 182.611414] R13: ffffffff90cf74d0 R14: 0000000000000000 R15: ffff99b1011e5800 [ 182.612009] FS: 0000000000000000(0000) GS:ffff99b1eaaee000(0000) knlGS:0000000000000000 [ 182.612670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 182.613146] CR2: 00000000005c631c CR3: 00000000013ee000 CR4: 00000000000006f0 [ 182.613722] Call Trace: [ 182.613946] [ 182.614130] __iterate_supers+0x128/0x150 [ 182.614463] do_thaw_all+0x1b/0x30 [ 182.614759] process_scheduled_works+0xbb/0x3f0 [ 182.615150] ? __pfx_worker_thread+0x10/0x10 [ 182.615499] worker_thread+0x129/0x270 [ 182.615816] ? __pfx_worker_thread+0x10/0x10 [ 182.616201] kthread+0xe2/0x120 [ 182.616469] ? __pfx_kthread+0x10/0x10 [ 182.616792] ret_from_fork+0x15b/0x240 [ 182.617115] ? __pfx_kthread+0x10/0x10 [ 182.617426] ret_from_fork_asm+0x1a/0x30 [ 182.617761] [ 182.617968] ---[ end trace 0000000000000000 ]--- [ 182.618412] Emergency Thaw complete Fix this by switching to SUPER_ITER_UNLOCKED and acquiring s_umount in the callback via super_lock_excl() before calling thaw_super_locked(). This matches the locking pattern expected by thaw_super_locked() and eliminates the double unlock. While at it, remove the dead 'return;' at the end of do_thaw_all_callback().", "cve_priority": "low", "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-68152", "url": "https://ubuntu.com/security/CVE-2026-68152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: fix use-after-free in AMT delayed works When an AMT device is removed, pending delayed works can still access the freed amt_dev structure, which may result in kernel crashes or memory corruption. amt_dev_stop() cancels req_wq and discovery_wq with cancel_delayed_work_sync(), but these works can be scheduled again from event_wq after the cancellation. This allows delayed works to access the freed amt_dev structure after the netdev has been released. The following is a simple race scenario: CPU0 CPU1 amt_dev_stop() cancel_delayed_work_sync() amt_event_work() mod_delayed_work(req_wq) free netdev req_wq accesses freed amt_dev Use disable_delayed_work_sync() in amt_dev_stop() to prevent req_wq and discovery_wq from being queued again and wait for running work items to complete. The delayed works are disabled after initialization in amt_newlink() and enabled only when the device is successfully opened. This keeps the delayed work lifecycle synchronized with the lifetime of the AMT device.", "cve_priority": "high", "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-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-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-68168", "url": "https://ubuntu.com/security/CVE-2026-68168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix afs_edit_dir_remove() to get, not find, block 0 Fix afs_edit_dir_remove() to use afs_dir_get_block() to get block 0 rather than afs_dir_find_block() as the latter caches the found block in the afs_dir_iter and may[*] switch out the page it's on if another afs_dir_find_block() is done. This parallels what afs_edit_dir_add() does. [*] There's more than one block per page.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68169", "url": "https://ubuntu.com/security/CVE-2026-68169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: userspace: fix use-after-free in get_local_id In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a \"not found\" sentinel.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68172", "url": "https://ubuntu.com/security/CVE-2026-68172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: make huge_ptep_get handled unaligned addresses huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma). The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned. On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map or into a hole, dereference a VA not mapped into the kernel pgtables and cause kernel panic. Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68174", "url": "https://ubuntu.com/security/CVE-2026-68174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix union collision of module and refcnt for dynamic events In 'struct trace_event_call', the 'module' pointer and the 'refcnt' atomic variable share the same memory space in a union. For dynamic events, the union member is 'refcnt', which acts as an active reference counter. When a dynamic event (such as kprobe, uprobe, fprobe, eprobe, or wprobe) has a non-zero reference count (e.g. due to active event triggers or perf attachments), its 'call->module' evaluates to a small non-zero integer instead of NULL. When filtering or setting events for a specific module (e.g., writing ':mod:' to 'set_event'), the code in '__ftrace_set_clr_event_nolock()' and 'update_event_fields()' reads 'call->module' directly without checking whether the event is dynamic. This causes the kernel to treat the small integer (refcnt) as a 'struct module' pointer, leading to a NULL/invalid pointer dereference (Oops) when dereferencing the module name. Fix this by ensuring that the 'TRACE_EVENT_FL_DYNAMIC' flag is checked before treating 'call->module' as a valid pointer in these code paths.", "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-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-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-68434", "url": "https://ubuntu.com/security/CVE-2026-68434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms Commit b1b4efea05a5 (\"serial: 8250_mid: Disable DMA for selected platforms\") replaced the dnv_board setup and exit callbacks with PTR_IF(false, ...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. Fix this by adding the missing NULL checks before calling the setup and exit callbacks.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17: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-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-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16: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-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-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-68198", "url": "https://ubuntu.com/security/CVE-2026-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix use-after-free in aggr_reset_state() The aggr_reset_state() function uses timer_delete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggr_module_destroy(). If the timer callback (aggr_timeout) is executing when aggr_reset_state() is called, the callback will continue to access aggr_conn fields like rx_tid[] and stat[] which may be freed immediately after by kfree(aggr_info->aggr_conn) in aggr_module_destroy(). Additionally, the timer callback can re-arm itself via mod_timer() while aggr_reset_state() is running, creating a more complex race condition. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "high", "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-68200", "url": "https://ubuntu.com/security/CVE-2026-68200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: don't re-enter an instance callback that is still running The userspace-driven timer (utimer) TRIGGER ioctl calls snd_timer_interrupt() directly with no serialization, so two threads triggering the same utimer can run snd_timer_interrupt() on one snd_timer concurrently. snd_timer_process_callbacks() drops timer->lock around each instance callback and marks the in-flight callback with the single SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that bit to drain an in-flight callback before freeing the instance. The bit cannot represent two concurrent callbacks: when a second interrupt re-queues an instance whose callback is still running, both run at once, the first to finish clears the bit, and the close-path drain then frees the instance (and its callback_data) while the other callback is still live - a use-after-free reachable by any user able to open /dev/snd/timer, both via a user timer instance and via a sequencer queue timer bound to the utimer. snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so a concurrent interrupt already observes it under the lock. Skip re-queuing an instance (and its slaves) to the ack/sack list while its callback is in flight; the accumulated pticks are delivered on the next tick, so no event is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68201", "url": "https://ubuntu.com/security/CVE-2026-68201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: drain a slave's callback before its master detaches it snd_timer_close_locked() drains the closing instance's own in-flight callback (IFLG_CALLBACK) before freeing it, but not its slaves'. When a master instance is closed, remove_slave_links() clears each slave's ->timer; the slave's own close then reads timer == NULL and takes the branch that skips the drain entirely (snd_timer_stop_slave() also no-ops on a NULL timer). So a slave whose callback is still running when the master is closed is freed underneath the live callback, leading to use-after-free. Drain the slaves too before remove_slave_links() severs them. snd_timer_stop() has already taken this instance off the active list, so no new slave callback can be queued. Take the slaves off the ack list so a pending one can't fire either, then wait for any that is already in flight.", "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-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-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-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-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-68211", "url": "https://ubuntu.com/security/CVE-2026-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32-dcmipp: 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. dcmipp_bytecap_start_streaming() returned -EINVAL when the source subdevice could not be resolved from the media graph, before pm_runtime_resume_and_get() and media_pipeline_start() had been called. The remaining error paths already converge on the err_buffer_done label, which calls dcmipp_bytecap_all_buffers_done(..., VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate err_pm_put / err_media_pipeline_stop 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": "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-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-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-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-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-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-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-68230", "url": "https://ubuntu.com/security/CVE-2026-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: amlogic-c3: Add validations for ae and awb config Avoid invalid memory access if the zones_num is bigger than zone_weight. This patch fixes the following smatch errors: drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max", "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-68232", "url": "https://ubuntu.com/security/CVE-2026-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path.", "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-68233", "url": "https://ubuntu.com/security/CVE-2026-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Shut down BO cache timer before teardown The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20: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-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-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-68238", "url": "https://ubuntu.com/security/CVE-2026-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Release VFCT ACPI table reference amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68239", "url": "https://ubuntu.com/security/CVE-2026-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Account for NULL and handle pages in ttm_pool_backup Pages in ttm_pool_backup can be NULL or backup handles (ttm_backup_page_ptr_is_handle()), neither of which can be passed to set_pages_array_wb() or freed. Add a dedicated WB pass before the dma/purge loop that walks allocations using the same i += num_pages stride, skipping NULL and handle entries, and calls set_pages_array_wb() once per contiguous run of real pages. Apply the same NULL/handle guard to the dma/purge loop. Fixes the following oops: Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI RIP: 0010:__cpa_process_fault+0xf8/0x770 RSP: 0018:ffffc90000a87718 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34 RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0 R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000 R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0 FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0 PKRU: 55555554 Call Trace: __change_page_attr_set_clr+0x989/0xe90 ? __purge_vmap_area_lazy+0x6c/0x3a0 ? _vm_unmap_aliases+0x250/0x2a0 set_pages_array_wb+0x7f/0x120 ttm_pool_backup+0x4c9/0x5b0 [ttm] ? dma_resv_wait_timeout+0x3b/0xf0 ttm_tt_backup+0x32/0x60 [ttm] ttm_bo_shrink+0x66/0x110 [ttm] xe_bo_shrink_purge+0x12b/0x1b0 [xe] xe_bo_shrink+0xbb/0x270 [xe] __xe_shrinker_walk+0xf7/0x160 [xe] xe_shrinker_walk+0x9d/0xc0 [xe] xe_shrinker_scan+0x11f/0x210 [xe] do_shrink_slab+0x13b/0x270 shrink_slab+0xf1/0x400 shrink_node+0x352/0x8a0 balance_pgdat+0x32c/0x700 kswapd+0x205/0x2f0 ? __pfx_autoremove_wake_function+0x10/0x10 ? __pfx_kswapd+0x10/0x10 kthread+0xd1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1b1/0x200 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68241", "url": "https://ubuntu.com/security/CVE-2026-68241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/mst: limit DP MST ESI service loop The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto. (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)", "cve_priority": "medium", "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-68245", "url": "https://ubuntu.com/security/CVE-2026-68245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only valid while the lock is still being held. Once xa_unlock_irqrestore is called and returned, the pointer is no longer under lock and is subject to modification. Since, the caller still dereferences vm->task_info in amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a use after unlock problem. Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid() through removing the amdgpu_vm_get_vm_from_pasid() function from amdgpu_vm.c and making the relevant code inline to hold the lock while it is still in use. (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)", "cve_priority": "high", "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-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-68252", "url": "https://ubuntu.com/security/CVE-2026-68252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68253", "url": "https://ubuntu.com/security/CVE-2026-68253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)", "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-68257", "url": "https://ubuntu.com/security/CVE-2026-68257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix 32-bit overflow in CWSR total size calculation total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68258", "url": "https://ubuntu.com/security/CVE-2026-68258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on CRIU restore queue type and mqd size We weren't checking whether the values provided in the private data in kfd CRIU restore were within bounds. For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it. For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations. (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)", "cve_priority": "low", "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-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-68266", "url": "https://ubuntu.com/security/CVE-2026-68266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68268", "url": "https://ubuntu.com/security/CVE-2026-68268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Return error on non-migratable faults requiring devmem Non-migratable faults that require devmem incorrectly jump to the 'out' label, which squashes the error code intended to be returned to the upper layers. Fix this by returning -EACCES instead. (cherry picked from commit c4508edb2c723de93717272488ea65b165637eac)", "cve_priority": "medium", "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-68270", "url": "https://ubuntu.com/security/CVE-2026-68270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Avoid possible truncation with calculating visible size Calculating the visible size of the system framebuffer can result in truncation of the result. The calculation uses 32-bit arithmetics, which can overflow if the values for height and stride are large. Fix the issue by multiplying with mul_u32_u32().", "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-68275", "url": "https://ubuntu.com/security/CVE-2026-68275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks up the bo_va for the buffer object in the caller's VM via amdgpu_vm_bo_find(), but uses the returned pointer without checking it. amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM, which is the normal case for a BO that has never been mapped. The result is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which expands to list_for_each_entry(mapping, &(bo_va)->valids, list) and dereferences bo_va, causing a NULL pointer dereference. This is reachable by any process able to issue the ioctl (render group) simply by requesting mapping info for an unmapped BO. Return -ENOENT when no bo_va is found, jumping to out_exec so the drm_exec context and GEM object reference are released. (cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68276", "url": "https://ubuntu.com/security/CVE-2026-68276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx: fix cleaner shader IB buffer overflow The cleaner shader sysfs path allocates a 16-dword (64 byte) IB but incorrectly fills (align_mask + 1) dwords. On GFX rings align_mask is 0xff, so the loop wrote 256 dwords into a 64-byte buffer, causing a kernel page fault. The IB only needs to be a minimal NOP shell to schedule the job; the cleaner shader itself is emitted on the ring via emit_cleaner_shader(). Fill 16 dwords to match the allocation. v2: Use ib_size_dw variable (Lijo) (cherry picked from commit bf21af331ebf72d0935fd70c73192414a422c03a)", "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-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-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-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-68282", "url": "https://ubuntu.com/security/CVE-2026-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: analogix_dp: Add missing error check for platform_get_resource() Add missing error check for platform_get_resource() return value to prevent NULL pointer dereference when memory resource is not available.", "cve_priority": "medium", "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-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-68292", "url": "https://ubuntu.com/security/CVE-2026-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues.", "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-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-68296", "url": "https://ubuntu.com/security/CVE-2026-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM Before commit 00d066a4d4ed (\"netdev_features: convert NETIF_F_LLTX to dev->lltx\"), NETIF_F_LLTX was set unconditionally in both __gre_tunnel_init() and ip6gre_tnl_init_features() alongside GRE_FEATURES: dev->features |= GRE_FEATURES | NETIF_F_LLTX; When that commit converted NETIF_F_LLTX to the dev->lltx flag, it placed 'dev->lltx = true' after the SEQ/CSUM early returns instead of before them. This causes GRE/GRETAP/ip6gre tunnels with SEQ or CSUM+encap to lose lockless TX, reintroducing _xmit_lock acquisition around their ndo_start_xmit. Since GRE xmit re-enters the stack via ip_tunnel_xmit(), holding _xmit_lock risks ABBA deadlock with the underlay device. CPU0 CPU1 ---- ---- lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); Fix by moving dev->lltx = true before the early returns in both functions, restoring the original unconditional behavior.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64575", "url": "https://ubuntu.com/security/CVE-2026-64575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: fix double sock release on batch realloc bpf_iter_tcp_batch() releases the current batch via bpf_iter_tcp_put_batch(), which drops the socket refs and rewrites each slot with the socket cookie, then grows the batch. cur_sk/end_sk are kept for bpf_iter_tcp_resume(), but on realloc failure the function returns ERR_PTR() before resume runs, leaving cur_sk < end_sk over slots that now hold cookies rather than sock pointers. bpf_iter_tcp_seq_stop() then calls bpf_iter_tcp_put_batch() again and dereferences a cookie as a struct sock. Empty the batch on the failure path so stop() does not release it again. The sockets were already freed by the first bpf_iter_tcp_put_batch(), so nothing leaks, and a later read() rescans the bucket from the start instead of skipping it. The sibling GFP_NOWAIT failure path still holds real socket references and is left for stop() to release. BUG: KASAN: null-ptr-deref in __sock_gen_cookie Read of size 8 at addr 0000000000000059 by task exploit ... __sock_gen_cookie (net/core/sock_diag.c:28) bpf_iter_tcp_put_batch (net/ipv4/tcp_ipv4.c:2918) bpf_iter_tcp_seq_stop (net/ipv4/tcp_ipv4.c:3270) bpf_seq_read (kernel/bpf/bpf_iter.c:205) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 entry_SYSCALL_64_after_hwframe Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68298", "url": "https://ubuntu.com/security/CVE-2026-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create() Commit 9e9787414882 (\"drm/xe/userptr: replace xe_hmm with gpusvm\") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a \"simple\" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). (cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4)", "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-68448", "url": "https://ubuntu.com/security/CVE-2026-68448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: check access to copy_file_range source with src mounter creds Commit 5dae222a5ff0c (\"vfs: allow copy_file_range to copy across devices\") allowed filesystems that implement the copy_file_range() f_op to decide if they want to access cross-sb copy from/to the same fs type. The same commit added checks to verify same sb copy for filesystems that implement ->copy_file_range() and do not support cross-sb copy at the time, namely, to ceph, fuse and nfs. The two remaining fs which implement ->copy_file_range(), cifs and overlayfs started to support cross-sb copy from this time. While overlayfs does support cross-sb copy when the two underlying files are on the same base fs, the copy operation on the two real files from two different overalyfs filesystems is performed with the mounter creds of the destination overlayfs and the read permission access hook for the source file was called with the wrong creds. This could cause either deny of access to copy which would otherwise be allowed (e.g. with splice) or allow read access to file which would otherwise be denied. Fix the latter case by explicitly verifying read access to source file with the source overlayfs mounter creds. The former case remains a quirk of cross-sb overlayfs copy, but userspace could fall back to regular copy so no harm done.", "cve_priority": "low", "cve_public_date": "2026-08-12 01:17: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-68307", "url": "https://ubuntu.com/security/CVE-2026-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix crash in reset link replay During reset recovery, mt7925_vif_connect_iter() replays firmware state for links tracked in mvif->valid_links. After MLO link changes or MCU timeout recovery, the driver bitmap can temporarily contain a link whose mac80211 bss_conf has already gone away. This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching the crash where x1, the second argument, is NULL: pc : mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] lr : mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] x2 : ffffff80a77f6018 x1 : 0000000000000000 x0 : ffffff8099402080 Call trace: mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common] Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA reset replay is unchanged because the helper still returns &vif->bss_conf for the legacy link.", "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-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-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-68311", "url": "https://ubuntu.com/security/CVE-2026-68311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: guard link STA in decap offload mt7925_sta_set_decap_offload() iterates over the vif valid_links mask when updating decap offload state for an MLO station. The station may not have a link STA for every valid link of the vif, so mt792x_sta_to_link() can return NULL for a link that belongs to the vif but not to the station. The function currently dereferences mlink before checking whether the link WCID is ready. If mlink is NULL, setting or clearing MT_WCID_FLAG_HDR_TRANS dereferences a NULL pointer. Skip links without a station link before touching mlink->wcid.", "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-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-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-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-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-68321", "url": "https://ubuntu.com/security/CVE-2026-68321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix FDIR filter leak on remove Perfect FDIR filters can be added while the interface is down and are kept on the software list for later restore. unregister_netdev() only calls ndo_stop when the device is up, so txgbe_fdir_filter_exit() in txgbe_close() is skipped in that case and the filters are leaked on driver remove. Free the filter list from txgbe_remove() as well.", "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-68330", "url": "https://ubuntu.com/security/CVE-2026-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix DMA direction for NPU mailbox buffer airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE, but some callers expect the NPU to write response data back into the same buffer: - airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into the buffer, then the caller reads it via memcpy() - airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back npu_stats_addr field in the response On non-cache-coherent architectures like EN7581 (Cortex-A53 without hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op — it does not invalidate the CPU cache. If the NPU-written cache line is still present in the CPU cache when the caller reads the buffer, the CPU observes stale data instead of the NPU response. This is a timing-sensitive bug: small mailbox buffers (~24 bytes) typically fit in a single cache line and may survive in the cache until the caller reads them, producing silent data corruption rather than a crash. The bug is more likely to trigger when the caller reads the response immediately after dma_unmap_single() without intervening cache-evicting operations. Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures dma_unmap_single() invalidates the CPU cache on non-coherent systems. The mailbox buffers are small so there is no performance concern.", "cve_priority": "low", "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-68332", "url": "https://ubuntu.com/security/CVE-2026-68332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix potential use-after-free in airoha_ppe_deinit() airoha_ppe_deinit() replaces the NPU pointer with NULL via rcu_replace_pointer() but does not wait for existing RCU readers to exit before calling ppe_deinit() and airoha_npu_put(). This can cause a use-after-free if a reader in an RCU read-side critical section still holds a reference to the NPU when it is freed. The init path (airoha_ppe_init) already calls synchronize_rcu() after rcu_assign_pointer(), but the deinit path introduced in commit 6abcf751bc08 (\"net: airoha: Fix schedule while atomic in airoha_ppe_deinit()\") omitted the matching barrier when switching from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer(). Add synchronize_rcu() before ppe_deinit() to ensure all existing RCU readers have completed before the NPU resources are released.", "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-68334", "url": "https://ubuntu.com/security/CVE-2026-68334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix io_thread race in rxrpc_wake_up_io_thread() rxrpc_wake_up_io_thread() checks local->io_thread before waking it, but then reloads the pointer for wake_up_process(). local->io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so the second load can see NULL even if the first load did not. Take a READ_ONCE() snapshot and use it for both the NULL check and the wake_up_process() call, as rxrpc_encap_rcv() already does.", "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-68341", "url": "https://ubuntu.com/security/CVE-2026-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix use after free in unlock_ovpn() unlock_ovpn() iterates over the release_list using llist_for_each_entry() and drops the peer reference inside the loop body via ovpn_peer_put(). If this drops the last reference, the peer is eventually freed. However, llist_for_each_entry() reads peer->release_entry.next in the loop advance expression, which runs after the body. By that time the peer may have already been freed, resulting in a use after free when advancing to the next list entry. Fix this by using llist_for_each_entry_safe(), which caches the next pointer before executing the loop body.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68342", "url": "https://ubuntu.com/security/CVE-2026-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: avoid putting unrelated P2P peer on socket release ovpn_peer_release_p2p() is called when an OVPN UDP socket is being destroyed. It checks the currently published P2P peer and releases it only if that peer still uses the socket being destroyed. A peer replacement can publish a new peer before the old UDP socket is destroyed. When the old socket destruction path runs afterwards, ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the new peer uses a different socket, the function takes the socket mismatch branch. That branch still calls ovpn_peer_put(peer). At this point, however, peer is the currently published replacement peer, not the peer associated with the socket being destroyed. Dropping its reference can free it while ovpn->peer still points to it, leading to later use-after-free accesses from the peer and socket cleanup paths. KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer object. In the reproducer, the object is allocated from ovpn_peer_new() via ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU callback processing. Observed access sites include ovpn_peer_remove(), ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn(). Fix this by returning from the socket mismatch branch without putting the peer.", "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-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-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-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-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-68356", "url": "https://ubuntu.com/security/CVE-2026-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: airoha: Prevent division by zero when clock frequency is zero clk_get_rate() can return 0 when the clock provider is not properly configured or the clock is unmanaged. The driver uses wdt_freq as a divisor directly in airoha_wdt_probe() to compute max_timeout and in airoha_wdt_get_timeleft() to compute the remaining time, which results in a division by zero. Add a check for wdt_freq == 0 in probe and return -EINVAL with dev_err_probe() to prevent the division by zero and provide a diagnostic message.", "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-68358", "url": "https://ubuntu.com/security/CVE-2026-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-kraken3) 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-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-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-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-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-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-68374", "url": "https://ubuntu.com/security/CVE-2026-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: sysfs: add lock to bos_descriptors_read() Add a lock to the function bos_descriptors_read(). This function accesses udev->bos, which could be simultaneously freed in usb_reset_and_verify_device(), a function that is commonly called in drivers all over the kernel.", "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-68378", "url": "https://ubuntu.com/security/CVE-2026-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions: - A pin is registered with two or more dpll devices (dpll_A, dpll_B) - The pin has ref_sync pairs with other pins - During unregistration of dpll_A's pins, a ref_sync partner pin is unregistered first, removing it from dpll_A->pin_refs - But since the partner pin is still registered with dpll_B, its dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT run and the partner stays in the pin's ref_sync_pins xarray - When the pin itself is then unregistered from dpll_A, the delete notification calls dpll_msg_add_pin_ref_sync() which finds the partner in ref_sync_pins, passes dpll_pin_available() (partner is still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A, partner) returns NULL because partner was already removed from dpll_A->pin_refs - The NULL priv pointer is passed to the driver's ref_sync_get callback, which dereferences it BUG: kernel NULL pointer dereference, address: 0000000000000034 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x] Call Trace: dpll_msg_add_pin_ref_sync+0xb8/0x200 dpll_cmd_pin_get_one+0x3b6/0x4b0 dpll_pin_event_send+0x72/0x140 __dpll_pin_unregister+0x5a/0x2b0 dpll_pin_unregister+0x49/0x70 Fix this by skipping ref_sync pins whose priv pointer cannot be resolved for the current dpll device.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68379", "url": "https://ubuntu.com/security/CVE-2026-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix TIME_WAIT socket reference leak on PSP policy failure Release the TIME_WAIT socket reference and jump to discard_it upon PSP policy failure in both IPv4 and IPv6 receive paths. This prevents a memory leak of tcp_tw_bucket structures.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68380", "url": "https://ubuntu.com/security/CVE-2026-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix use-after-free of mm_struct in job scheduler amdxdna_cmd_submit() stores current->mm in job->mm without holding any reference. aie2_sched_job_run() later access job->mm from the DRM scheduler worker thread. With only a raw pointer and no structural reference, the mm_struct can be freed before the scheduler runs the job. Fix this by calling mmgrab() to hold a structural mm_count reference for the lifetime of the job, paired with mmdrop() in every cleanup path.", "cve_priority": "high", "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-68384", "url": "https://ubuntu.com/security/CVE-2026-68384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits. - Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it. While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one. (cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68385", "url": "https://ubuntu.com/security/CVE-2026-68385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/checksum: Fix csum_partial() without vector facility Currently csum_partial() calls csum_copy() with copy=false and dst=NULL. On machines without the vector facility, csum_copy() falls back to cksm(dst, ...), causing the checksum to be calculated from address zero instead of the source buffer. The VX implementation already checksums data loaded from src. Make the fallback do the same by passing src to cksm().", "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-68387", "url": "https://ubuntu.com/security/CVE-2026-68387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: add locking for raw flags bitfield With commit 890e5198a6e5 (\"can: raw: use bitfields to store flags in struct raw_sock\") the formerly separate integer values have been integrated into a single bitfield. This led to a read-modify-write operation when changing a flag in raw_setsockopt() which now needs a locking to prevent concurrent access. Instead of adding a lock/unlock hell in each of the flag manipulations this patch introduces a wrapper for a new raw_setsockopt_locked() function analogue to the isotp_setsockopt[_locked]() approach in net/can/isotp.c [mkl: use Closes tag instead of Link]", "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-68393", "url": "https://ubuntu.com/security/CVE-2026-68393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: extend conn_hash lookup critical sections Using RCU-protected pointers outside the critical sections without refcount is incorrect and may result to UAF. Extend critical section to cover both hci_conn_hash lookup and use of the returned conn. Add surrounding rcu_read_lock() also when return value is not used, in preparation for RCU lockdep requirement to hci_lookup_le_connect(). This avoids concurrent deletion of the conn before we are done dereferencing it. Also, make sure to hold hdev->lock when accessing hdev->accept_list.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68394", "url": "https://ubuntu.com/security/CVE-2026-68394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update MGMT_OP_LOAD_CONN_PARAM queues conn_update_sync() when a single parameter update changes an existing LE central connection. The queued work currently stores a borrowed hci_conn_params entry from hdev->le_conn_params. A later LOAD_CONN_PARAM request can clear disabled parameters and free that entry before hci_cmd_sync_work() runs the queued callback. Do not keep the borrowed hci_conn_params pointer in queued work. Queue the hci_conn instead and hold a reference until the queued callback completes. When the work runs, revalidate that the connection is still present, look up the current hci_conn_params entry, and cancel the update if userspace removed that entry while the work was pending. Copy the interval values from the current params entry under hdev->lock, then drop the lock and keep using hci_le_conn_update_sync() to issue the update. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in conn_update_sync+0x2a/0xf0 [bluetooth] Read of size 1 at addr ffff88810c697126 by task kworker/u17:0/377 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 kasan_report+0xe0/0x110 conn_update_sync+0x2a/0xf0 [bluetooth] hci_cmd_sync_work+0x187/0x210 [bluetooth] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 Allocated by task 466: hci_conn_params_add+0xa6/0x240 [bluetooth] load_conn_param+0x4e1/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] Freed by task 474: kfree+0x313/0x590 hci_conn_params_clear_disabled+0x9b/0xc0 [bluetooth] load_conn_param+0x4bf/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth]", "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-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-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-68400", "url": "https://ubuntu.com/security/CVE-2026-68400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint memory access array and to comply with the FF-A spec instead of defaulting to `sizeof(struct ffa_mem_region)`. This requires moving `ffa_mem_region_additional_setup()` earlier in the setup flow. Also, add sanity checks to ensure the calculated descriptor offsets do not exceed `max_fragsize`.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68401", "url": "https://ubuntu.com/security/CVE-2026-68401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() Sashiko (locally) reports multiple out-of-bound issues in ffa_setup_and_transmit: 1) Writing ep_mem_access->reserved can write out of bounds for FFA versions < 1.2 as ffa_emad_size_get() returns 16 bytes in that case while reserved has an offset of 24. Instead of zeroing fields, memset the struct to zero first based on the FFA version. 2) Make sure there is enough size to write constituents. While at it, convert the only sizeof() in the driver that uses a type instead of variable.", "cve_priority": "high", "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-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-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-68409", "url": "https://ubuntu.com/security/CVE-2026-68409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: defer link RX stats percpu free to RCU sta_remove_link() frees a removed MLO link's RX stats percpu buffer right away, but defers only the link container to RCU: \tsta_info_free_link(&alloc->info); \tkfree_rcu(alloc, rcu_head); The RX fast path reads link_sta under rcu_read_lock and writes the percpu stats. A reader that resolved link_sta before the removal keeps the pointer. The container stays alive from the kfree_rcu, so the read still works. But the percpu block it points to is already freed. This needs uses_rss. That is when pcpu_rx_stats exists. The full STA teardown frees the deflink stats only after synchronize_net(). The link removal path had no such barrier. The race is hard to win in practice, but the free should still wait for RCU. Free the link together with its data from a single RCU callback, so the percpu block is reclaimed only after readers drain.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20: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-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-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-68412", "url": "https://ubuntu.com/security/CVE-2026-68412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan() If the test against IEEE80211_MAX_SSID_LEN fails, then 'creq' leaks. Use the existing error handling path to fix it.", "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-64566", "url": "https://ubuntu.com/security/CVE-2026-64566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags() When iptfs_skb_add_frags() copies frag references from the source frag walk into a new SKB, it increments the page reference count via __skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the destination SKB's skb_shinfo->flags. If the source SKB carries shared frags (e.g. from a page-pool backed receive path), the new inner SKB will appear to ESP as having privately owned frags. A subsequent esp_input() call for a nested transport-mode SA then takes the no-COW fast path and decrypts in place, writing over pages that are still referenced by the outer IPTFS SKB. This causes kernel-visible memory corruption and can trigger a panic. All other frag-transfer helpers in the kernel (skb_try_coalesce, skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this convention by setting the flag inside the loop immediately after __skb_frag_ref() and nr_frags++, so every exit path that attaches a frag unconditionally propagates SKBFL_SHARED_FRAG.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68415", "url": "https://ubuntu.com/security/CVE-2026-68415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear mode callbacks after failed mode setup xfrm_state_gc_task can run long after a failed IPTFS state setup. In the reproduced case, __xfrm_init_state() cached x->mode_cbs, IPTFS setup returned -ENOMEM before publishing mode_data, and the temporary module reference from xfrm_get_mode_cbs() was dropped immediately. The dead state then kept x->mode_cbs until deferred GC ran after xfrm_iptfs had been unloaded. Clear x->mode_cbs when mode init or clone fails before publishing mode_data. Those states never installed mode-specific state or the long-term IPTFS module pin, so deferred GC has nothing mode-specific to destroy and must not retain a callback table pointer past the temporary lookup reference. The buggy scenario involves two paths, with each column showing the order within that path: failed setup path: 1. cache x->mode_cbs 2. mode setup fails before mode_data 3. drop the temporary module ref 4. dead state keeps x->mode_cbs cached GC/unload path: 1. xfrm_state_put() queues GC work 2. xfrm_iptfs unloads later 3. xfrm_state_gc_task runs 4. GC dereferences stale x->mode_cbs This also covers the failed clone path where clone_state() returns before publishing mode_data. Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y failslab_stacktrace_filter matched xfrm_iptfs frames ack_error=-12 FAULT_INJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrm_state_gc_task RIP: xfrm_state_gc_task+0x142/0x650 Modules linked in: esp4_offload xfrm_user [last unloaded: xfrm_iptfs] Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68418", "url": "https://ubuntu.com/security/CVE-2026-68418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent user-triggered null deref on QP create Previously, the user QP creation path would only attempt to populate iwqp->iwpbl if the user-provided req.user_wqe_bufs field was non-zero. The problem is that iwqp->iwpbl is unconditionally dereferenced later on in irdma_setup_virt_qp. While there was a check for iwqp->iwpbl != NULL, this check would only occur if req.user_wqe_bufs was non-zero. The end result is that a user could send a zero user_wqe_bufs value and trigger a null ptr deref. Fix this by unconditionally calling irdma_get_pbl and bailing if it fails, similar to the CQ and SRQ paths.", "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-68420", "url": "https://ubuntu.com/security/CVE-2026-68420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: reject optional IPTFS templates in outbound policies syzbot reported a stack-out-of-bounds read in xfrm_state_find() which flows from xfrm_tmpl_resolve_one(). Commit 3d776e31c841 (\"xfrm: Reject optional tunnel/BEET mode templates in outbound policies\") disallowed optional tunnel and BEET in outbound policies to prevent this. Later when IPTFS added, it was not covered by that fix and can still trigger the out-of-bounds read; Extend the check to disallow optional IPTFS in outbound policies as well. IPTFS should be identical to tunnel mode. IN and FWD policies are not affected: xfrm_tmpl_resolve_one() is only reachable via the outbound path. Reproducer, before: ip link add dummy0 type dummy ip link set dummy0 up ip addr add 10.1.1.1/24 dev dummy0 ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 mode transport ping -W 1 -c 1 10.1.1.2 PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data. [ 64.168420] ================================================================== [ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844 [ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full) [ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 64.169977] Call Trace: [ 64.169977] [ 64.169977] dump_stack_lvl+0x47/0x70 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] print_report+0x152/0x4b0 [ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0 [ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20 [ 64.169977] ? __virt_addr_valid+0x21b/0x230 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] kasan_report+0xa8/0xd0 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm_dst_hash+0x24/0xc0 [ 64.169977] xfrm_state_find+0xa2d/0x2f90 [ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570 [ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10 [ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 64.169977] ? kernel_text_address+0x5b/0x80 [ 64.169977] ? __kernel_text_address+0xe/0x30 [ 64.169977] ? unwind_get_return_address+0x5e/0x90 [ 64.169977] ? arch_stack_walk+0x8c/0xe0 [ 64.169977] xfrm_tmpl_resolve+0x130/0x200 [ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10 [ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110 [ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10 [ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310 [ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80 [ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10 [ 64.169977] ? ip_route_output_key_hash+0xc6/0x110 [ 64.169977] ? kasan_save_track+0x10/0x30 [ 64.169977] xfrm_lookup_route+0x18/0xe0 [ 64.169977] ip4_datagram_release_cb+0x4c9/0x530 [ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10 [ 64.169977] ? do_raw_spin_lock+0x71/0xc0 [ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 64.169977] release_sock+0xb0/0x170 [ 64.169977] udp_connect+0x43/0x50 [ 64.169977] __sys_connect+0xa6/0x100 [ 64.169977] ? alloc_fd+0x2e9/0x300 [ 64.169977] ? __pfx___sys_connect+0x10/0x10 [ 64.169977] ? preempt_latency ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68421", "url": "https://ubuntu.com/security/CVE-2026-68421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx() put_prev_task_scx() warns when a runnable task drops to a lower sched_class without SCX_OPS_ENQ_LAST, on the assumption that balance_one() would have kept it running. Core scheduling breaks that: a forced-idle SMT sibling reschedules through the core_pick fast path in pick_next_task(), which skips pick_task_scx() and thus balance_one(), so a runnable task can drop to idle with ENQ_LAST unset. Gate the warning on sched_cpu_cookie_match(): a cookie mismatch means core scheduling forced the idle, while a match (or core scheduling off) still catches a genuine missing-ENQ_LAST drop.", "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-68426", "url": "https://ubuntu.com/security/CVE-2026-68426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix stale skb->prev after async crypto steals a GSO segment skb_gso_segment() leaves the segment list head with ->prev pointing at the last segment, an invariant validate_xmit_skb_list() relies on when it sets its tail pointer (tail = skb->prev). When validate_xmit_xfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validate_xmit_skb_list() later does tail->next = skb, writing through that stale pointer -- a use-after-free. Repoint skb->prev at the last retained segment before returning.", "cve_priority": "critical", "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-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-2023-20585", "url": "https://ubuntu.com/security/CVE-2023-20585", "cve_description": "Insufficient checks of the RMP on host buffer access in IOMMU may allow an attacker with privileges and a compromised hypervisor to trigger an out of bounds condition without RMP checks, resulting in a potential loss of confidential guest integrity.", "cve_priority": "low", "cve_public_date": "2026-04-16 19:16:00 UTC" }, { "cve": "CVE-2026-68364", "url": "https://ubuntu.com/security/CVE-2026-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix ISM dc_lock deadlock during suspend [Why] System hang observed during suspend/resume while video is playing. amdgpu_dm_ism_disable() is called under dc_lock and waits for ISM delayed work via disable_delayed_work_sync(). The work handlers themselves take dc_lock, producing an ABBA deadlock when a worker is in flight at suspend time. [How] Split the disable path into two phases with opposite locking contracts: 1. amdgpu_dm_ism_disable() -- quiesces workers, must NOT hold dc_lock. 2. amdgpu_dm_ism_force_full_power() (new) -- drives the ISM FSM back to FULL_POWER_RUNNING, must hold dc_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72064", "url": "https://ubuntu.com/security/CVE-2026-72064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Sync page pool RX frags for CPU MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack.", "cve_priority": "medium", "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-72098", "url": "https://ubuntu.com/security/CVE-2026-72098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: fix buffer overflow in FEC calculation There's a buffer overflow in dm-verity-fec: if (neras && *neras <= v->fec->roots) \tfio->erasures[(*neras)++] = i; This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72248", "url": "https://ubuntu.com/security/CVE-2026-72248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: support IPIP tunnel with direct xmit The combination of IPIP tunnel with direct xmit, eg. bridge device, breaks because no dst_entry is provided to check the skb headroom and to set the iph->frag_off field. This leads to invalid dst usage and can trigger a crash in the tunnel transmit path. Fix this by moving dst_cache and dst_cookie out of the runtime union so that they can be shared by neighbour, xfrm, and direct tunnel flows. For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve route state in these shared fields and release it through the common dst release path. Since dst_entry is now available to the three supported xmit modes and dst_release() already deals with NULL dst, remove the xmit type check in nft_flow_dst_release(). Moreover, skip the check if the dst entry is NULL in nf_flow_dst_check() which is now the case for the direct xmit case. Based on patch from Rein Wei .", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72249", "url": "https://ubuntu.com/security/CVE-2026-72249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: use dst in this direction when pushing IPIP header When pushing the IPIP header, the route of the other direction is used to calculate the headroom, use the route in this direction. Accessing the other tuple to set the IP source and destination is fine because this tuple does not provide such information to avoid storing redundant information. However, this tuple already provides the dst for this direction, this went unnoticed because this bug affects headroom and iph->frag_off only at this stage.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72287", "url": "https://ubuntu.com/security/CVE-2026-72287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the \"normal\" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a \"late\" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72329", "url": "https://ubuntu.com/security/CVE-2026-72329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/liquidio: drop cached VF pci_dev LUT The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST. Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72355", "url": "https://ubuntu.com/security/CVE-2026-72355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix barriering when walking subrequest list Fix the barriering used when walking the subrequest list in retry as there's a possibility of seeing a subreq that's just been added by the application thread.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72412", "url": "https://ubuntu.com/security/CVE-2026-72412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/mm: Fix handling of _PAGE_UNUSED pte bit The _PAGE_UNUSED softbit should not really be lying around. Its sole purpose is to signal to try_to_unmap_one() and try_to_migrate_one() that the page can be discarded instead of being moved / swapped. KVM has no way to know why a page is being unmapped, so it sets the bit on userspace ptes corresponding to unused guest pages every time they get unmapped. KVM has no reasonable way to clear the bit once the page is in use again. While set_ptes() checks and clears the bit, other paths that set new ptes did not. This led to used pages being thrown out as if they were unused, causing guest corruption. Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in set_pte(), i.e. whenever a present pte is getting set. The check in set_ptes() is then redundant and can be removed. Also fix gmap_helper_try_set_pte_unused() to only set the bit if the pte is present; the _PAGE_UNUSED bit is only defined for present ptes and thus should not be set for non-present ptes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72417", "url": "https://ubuntu.com/security/CVE-2026-72417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto() Add sanity check for iph->ihl field in nf_flow_ip4_tunnel_proto() before using it to compute the header size, avoiding out-of-bounds access with malformed IP headers. While at it, use iph->protocol instead of the hardcoded IPPROTO_IPIP constant when setting ctx->tun.proto and reference ctx->tun.hdr_size when updating ctx->offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72442", "url": "https://ubuntu.com/security/CVE-2026-72442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: fix and simplify IP6IP6 tunnel handling Fix nf_flow_ip6_tunnel_proto() to use pskb_may_pull() instead of skb_header_pointer() to ensure the outer IPv6 header is in the skb headroom, which is required for subsequent packet processing. Move ctx->offset update inside the IPPROTO_IPV6 conditional block since it should only be adjusted when an IP6IP6 tunnel is actually detected. Simplify the rx path by removing ipv6_skip_exthdr() and checking ip6h->nexthdr directly, as the flowtable fast path only handles simple IP6IP6 encapsulation without extension headers. Drop the tunnel encapsulation limit destination option support from the tx path to match, since the rx path no longer handles extension headers. Remove the encap_limit parameter from nf_flow_offload_ipv6_forward(), nf_flow_tunnel_ip6ip6_push() and nf_flow_tunnel_v6_push(), along with the ipv6_tel_txoption struct and related headroom/MTU adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72463", "url": "https://ubuntu.com/security/CVE-2026-72463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix dev use-after-free in xfrm async resumption xfrm async resumption hold skb->dev refcnt until after transport_finish. However, xfrm_rcv_cb may modify skb->dev to tunnel dev without taking device reference, such as vti_rcv_cb. The subsequent async resumption will decrement the tunnel device's reference count, which lead to uaf of tunnel dev and refcnt leak of orig dev as below: unregister_netdevice: waiting for vti1 to become free. Usage count = -2 Stash the original skb->dev to fix refcnt imbalance. The new skb->dev set by xfrm_rcv_cb can race with device teardown. Extend rcu protection over xfrm_rcv_cb and transport_finish to prevent races.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72477", "url": "https://ubuntu.com/security/CVE-2026-72477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: call _ntfs_bad_inode() when failing to rename It is safe to call _ntfs_bad_inode on live inodes since: commit 519b078998ce (\"fs/ntfs3: Exclude call make_bad_inode for live nodes.\") The WARN_ON was added when it wasn't safe by: commit d99208b91933 (\"fs/ntfs3: cancle set bad inode after removing name fails\") Replace the WARN_ON with a call to _ntfs_bad_inode() to prevent further operations on the inconsistent inode.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72493", "url": "https://ubuntu.com/security/CVE-2026-72493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: serialize netif_running() check in enqueue_to_backlog() Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup(). The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit). Commit e9e4dd3267d0 (\"net: do not process device backlog during unregistration\") introduced a lockless netif_running() check in enqueue_to_backlog() to prevent queuing packets to an unregistering device. However, this creates a TOCTOU race window. A lockless transmitter (like veth_xmit) can pass the check before dev_close() clears IFF_UP. If the transmitter is then delayed, flush_all_backlogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed. Fix this by moving the netif_running() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netif_running() after the flush/close completes (so it gets dropped).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72494", "url": "https://ubuntu.com/security/CVE-2026-72494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Replace waitqueue and flag with completion The driver previously used a waitqueue along with an explicit request_done flag, but without proper barriers around request_done. An earlier patch by Gui-Dong Han attempted to fix this by adding the missing memory barriers. Rather than adding the barriers, this patch replaces the waitqueue+flag with a completion, which is designed for this exact purpose.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72496", "url": "https://ubuntu.com/security/CVE-2026-72496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Proper rollback if the ioremap fails bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74269", "url": "https://ubuntu.com/security/CVE-2026-74269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt: fix head underflow on XDP head-grow The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free. The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with this commit applied causes the test to run successfully to completion. The other rx_skb_func implementations don't have this issue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74350", "url": "https://ubuntu.com/security/CVE-2026-74350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate fast symlink target during inode read ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment. A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer. Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated. This keeps malformed fast symlinks from reaching the read path. Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x19f/0x330 (?:?) kasan_report+0xe0/0x110 (?:?) kasan_check_range+0x105/0x1b0 (?:?) __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72495", "url": "https://ubuntu.com/security/CVE-2026-72495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid repeated requests to allocate WC pages Applications can request multiple WC pages for the same ucontext. As of now, only 1 WC page per ucontext is supported. Add a lock to avoid concurrent access and a check to fail repeated requests. Also, if the mmap entry insert fails for the WC, free the Doorbell page index mapped for the WC page.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72501", "url": "https://ubuntu.com/security/CVE-2026-72501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Initialize dpi variable to zero dpi is initialized only for BNXT_RE_ALLOC_WC_PAGE, but copied for all the cases. So initialize the dpi to 0.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72278", "url": "https://ubuntu.com/security/CVE-2026-72278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Re-translate VNCR before injecting abort KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor updates and MMU faults.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68083", "url": "https://ubuntu.com/security/CVE-2026-68083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix path resolution in ksmbd_vfs_kern_path_create The SMB2 open lookup is rooted at the share with LOOKUP_BENEATH, but the create/mkdir/hardlink sink is not: ksmbd_vfs_kern_path_create() builds an absolute path with convert_to_unix_name() and resolves it from AT_FDCWD via start_creating_path(), so a \"..\" component is walked from the real filesystem root and escapes the export. An authenticated client races a missing path component so the rooted open lookup returns -ENOENT (taking the create branch) while the same component is present (a directory) when the create walk runs; the create then resolves \"..\" out of the share. Root the create walk at the share like the lookup and rename paths already are: resolve the parent with vfs_path_parent_lookup(..., LOOKUP_BENEATH, &share_conf->vfs_path) and create the final component with start_creating_noperm(). convert_to_unix_name() then has no callers and is removed.", "cve_priority": "high", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-68457", "url": "https://ubuntu.com/security/CVE-2026-68457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use opener credentials for FSCTL mutations SET_SPARSE, SET_ZERO_DATA and SET_COMPRESSION operate on an open SMB handle but call VFS xattr, fallocate or fileattr helpers with the current ksmbd worker credentials. Those helpers can revalidate inode permissions, ownership and LSM policy independently of the SMB handle access mask. Run each operation with the credentials captured in the target file when the handle was opened. Keep credential handling local to these single-file FSCTLs rather than applying session credentials to the complete IOCTL handler, which also contains handle-less and multi-handle operations.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72041", "url": "https://ubuntu.com/security/CVE-2026-72041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: use sk_msg_free_partial to fix partial send sk_msg_free_partial() ensures consistency of the skmsg at every iteration, without having to manually handle uncharges and offsets. This simplifies the code, and fixes some bugs in skmsg accounting when we don't send the full contents.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72046", "url": "https://ubuntu.com/security/CVE-2026-72046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing.", "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-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21: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-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72137", "url": "https://ubuntu.com/security/CVE-2026-72137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: nat_keepalive: avoid double free on send error nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6 send helper reports an error. That cleanup is only correct before the skb is handed to the output path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the networking stack may already have consumed the skb before returning an error, so freeing it again is unsafe. Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4() and nat_keepalive_send_ipv6(), where the caller still owns the skb, and keep nat_keepalive_send() responsible only for family dispatch and the unsupported-family cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72139", "url": "https://ubuntu.com/security/CVE-2026-72139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: defer md5sig_info kfree past RCU grace period in tcp_connect The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: \tif (needs_md5) { \t\ttcp_ao_destroy_sock(sk, false); \t} else if (needs_ao) { \t\ttcp_clear_md5_list(sk); \t\tkfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); \t} Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with tcp-diag]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72191", "url": "https://ubuntu.com/security/CVE-2026-72191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: validate split-point offset in indx_insert_into_buffer indx_insert_into_buffer() computes used = used1 - to_copy - sp_size; memmove(de_t, Add2Ptr(sp, sp_size), used - le32_to_cpu(hdr1->de_off)); where sp and sp_size come from hdr_find_split(). hdr_find_split() walks entries by le16_to_cpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFS_DE). index_hdr_check(), the on-load gatekeeper, only validates header-level fields (used, total, de_off) and does not walk per-entry sizes. A crafted NTFS image whose leaf INDEX_HDR reports used == total but contains one interior NTFS_DE with size = 0xFFF0 therefore passes validation, descends to indx_insert_into_buffer() through the ntfs_create() -> indx_insert_entry() path, and makes hdr_find_split() return an sp whose sp_size (0xFFF0) greatly exceeds the remaining bytes in the buffer. The u32 subtraction underflows and the memmove count becomes a near-4-GiB value, producing an out-of-bounds kernel write that corrupts adjacent allocations and panics the kernel. Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a single 'touch' inside the mounted directory; crash site resolves to fs/ntfs3/index.c at the memmove. Trigger requires only local mount of an attacker-supplied filesystem image (USB, loopback, or removable media auto-mount). Reject the split whenever the chosen sp plus its declared size already extends past hdr1->used. This is the minimal fix; it preserves the existing hdr_find_split() contract and relies on the same out: cleanup path as the pre-existing error returns. A prior OOB read in the very same indx_insert_into_buffer() memmove was fixed in commit b8c44949044e (\"fs/ntfs3: Fix OOB read in indx_insert_into_buffer\") by tightening hdr_find_e(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdr_find_split(), not hdr_find_e(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72217", "url": "https://ubuntu.com/security/CVE-2026-72217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing xdr_buf_to_bvec() writes a bio_vec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it. rq_bvec, the array passed by nfsd_vfs_write(), is allocated to exactly rq_maxpages entries with no slack. The OOB store can land in adjacent slab memory; the bv_len and bv_offset fields written there are derived from client-supplied RPC payload sizes. Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72220", "url": "https://ubuntu.com/security/CVE-2026-72220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp->rq_procinfo->pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72221", "url": "https://ubuntu.com/security/CVE-2026-72221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: wait for in-flight TLS handshake callback when cancel loses race When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed. The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result. If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue. If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed. Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed to fire because handshake_complete() invokes svc_tcp_handshake_done() unconditionally once it has set HANDSHAKE_F_REQ_COMPLETED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72222", "url": "https://ubuntu.com/security/CVE-2026-72222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: pin svc_xprt across the asynchronous TLS handshake callback svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of(). Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done. The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry. Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all(). [cel: rewrote commit message to describe the actual change]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72277", "url": "https://ubuntu.com/security/CVE-2026-72277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the simpler thing for now and just reject everything that isn't memory.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72279", "url": "https://ubuntu.com/security/CVE-2026-72279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR KVM currently maps the L1 VNCR into the host stage-1 by relying entirely on the permissions of the guest stage-1. At the same time, it is entirely possible that the backing PFN is read-only (e.g. RO memslot), meaning that the L1 VNCR should use at most a read-only mapping. Cache the writability of the PFN in the VNCR TLB and use it to constrain the resulting fixmap permissions. Promote VNCR permission faults to an SEA in the case where the guest attempts to write to a read-only endpoint. Conveniently, this also plugs a page leak found by Sashiko [*] resulting from the early return for a read-only PFN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72288", "url": "https://ubuntu.com/security/CVE-2026-72288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling Hyunwoo Kim reports some really bad races should the following situation occur: - LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C If the last two race nicely enough, vgic_prune_ap_list() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows. The fix is two-fold: - Before dropping the irq and ap_list locks, take a reference on the irq - Do not try to handle migration of the pending bit: there is no expectation that this state is retained, as per the architecture With that, we're sure that the interrupt is still around, and we safely remove it from the AP list as it has no target at this stage (unless another interrupt fires, but that's another story).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "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-72317", "url": "https://ubuntu.com/security/CVE-2026-72317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: pin upper rpc_clnt across the TLS connect_worker The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt. The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported. Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one. The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72318", "url": "https://ubuntu.com/security/CVE-2026-72318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate DFS referral string offsets parse_dfs_referrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server. Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative max_len is then passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds. Validate each string offset before deriving the string pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72320", "url": "https://ubuntu.com/security/CVE-2026-72320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_lookup: fix catchall element handling with inverted lookups nft_lookup_eval() decides whether a lookup matched (`found`) from the direct set lookup and priv->invert before falling back to the catchall element used by interval sets (e.g. nft_set_rbtree) for the open-ended default range. Since `found` is never recomputed after `ext` is replaced by the catchall lookup, inverted lookups (NFT_LOOKUP_F_INV, \"!= @set\") can wrongly match or wrongly skip the catchall element, producing the wrong verdict. Fold the catchall lookup into `ext` before computing `found`, matching the order already used by nft_objref_map_eval().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72366", "url": "https://ubuntu.com/security/CVE-2026-72366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_create_write_req() to handle async cache object creation netfs_create_write_req() will skip caching if the fscache cookie is disabled, but this is a problem because async cache object creation might not have got far enough yet that has been enabled - thereby causing the call to fscache_begin_write_operation() to be skipped. Fix this by removing the checks on the cookie and delegating this to fscache_begin_write_operation().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72381", "url": "https://ubuntu.com/security/CVE-2026-72381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of fp->owner.name in durable handle owner check Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d (\"ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd\") made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized. BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8 Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72393", "url": "https://ubuntu.com/security/CVE-2026-72393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: don't cache shinfo across skb realloc fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb including the shared info. We can't use the pointer calculated before the call. BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0 Read of size 4 at addr ff110000262edd98 by task swapper/5/0 Call Trace: fbnic_tx_lso.isra.0+0x668/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 Allocated by task 8653: __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xcc/0x6c0 sock_alloc_send_pskb+0x327/0x3f0 __ip_append_data+0x188b/0x47a0 ip_make_skb+0x24a/0x300 udp_sendmsg+0x14d2/0x21e0 Freed by task 0: kfree+0x123/0x5a0 pskb_expand_head+0x36c/0xfa0 fbnic_tx_lso.isra.0+0x500/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 sch_direct_xmit+0x25b/0x1100 The buggy address belongs to the object at ff110000262edc40 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 344 bytes inside of freed 640-byte region [ff110000262edc40, ff110000262ede", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72398", "url": "https://ubuntu.com/security/CVE-2026-72398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: add INIT verification after cookie unpacking In SCTP handshake, the INIT chunk is initially processed by the server and embedded into the cookie carried in INIT-ACK. The client then returns this cookie via COOKIE-ECHO, where the server unpacks it and reconstructs the original INIT chunk. When cookie authentication is enabled, the cookie contents are protected against tampering, so reusing the unpacked INIT without re-verification is safe. However, when cookie authentication is disabled, the reconstructed INIT can no longer be trusted. In this case, the INIT must be explicitly validated after unpacking to avoid processing potentially tampered data. Add sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO processing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook()) when cookie_auth_enable is disabled. On failure, the new association is freed and the packet is discarded. Also tighten cookie validation in sctp_unpack_cookie() by verifying the embedded chunk type is SCTP_CID_INIT before treating it as an INIT chunk. Finally, update sctp_verify_init() to validate parameter bounds using the actual embedded INIT length instead of chunk->chunk_end, since the INIT stored in COOKIE-ECHO may not span the entire chunk buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72399", "url": "https://ubuntu.com/security/CVE-2026-72399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: check the number of BDs needed for xdp_frame The size of xdp_redirect_arr array is ENETC_MAX_SKB_FRAGS. However, the number of fragments contained in xdp_frame may be greater than or equal to ENETC_MAX_SKB_FRAGS, which will cause the access to xdp_redirect_arr to be out of bounds.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72429", "url": "https://ubuntu.com/security/CVE-2026-72429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix type confusion of dst_entry IOAM uses a dummy dst_entry(null_dst) to mark that the destination should not be changed after the transformation. This dst is stored in the IOAM lwt state and may be passed to dst_cache_set_ip6(). However, the IPv6 dst cache path eventually calls rt6_get_cookie(), which treats the dst_entry as part of a struct rt6_info. Since the null_dst was embedded directly as a struct dst_entry in struct ioam6_lwt, this resulted in an invalid cast and rt6_get_cookie() reading fields from the wrong object. In practice, the wrong cookie is not used while dst->obsolete is zero, but rt6_get_cookie() may also access per-cpu value when rt->sernum is zero. In this case, rt->sernum aliases ioam6_lwt::cache::reset_ts, which can become zero, making this a potential invalid pointer access. Fix this by embedding a full struct rt6_info for the dummy IPv6 route and passing its dst member to the dst APIs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72436", "url": "https://ubuntu.com/security/CVE-2026-72436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash types Sashiko pointed out that there are a few lockless RCU readers using test_bit() which is a relaxed atomic operation and provides no memory barrier guarantees. Use test_bit_acquire() instead where the operation may run parallel with add/del/gc, i.e. is not one from the next cases - protected by region lock - in a set destroy phase - in a new/temporary set creation phase", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72451", "url": "https://ubuntu.com/security/CVE-2026-72451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix xfrm state cache insertion race The xfrm input state cache insertion code checks the validity of the state before acquiring the global xfrm_state_lock. Thus it's possible for someone else to kill the state after it passed the validity check, and then the insertion will add the dead state to the cache. Fix this by moving the validity check inside the lock. This entire function is called on the input path, where BH must be off (e.g., the caller of this function xfrm_input acquires its spinlocks without disabling BH). So there is no need to disable BH here or take the RCU read lock. Remove both and replace them with an assertion that trips if BH is accidentally enabled on some future calling path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72472", "url": "https://ubuntu.com/security/CVE-2026-72472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: use nfsi->rwsem to protect traversal of the file lock list Lingfeng identified a bug and suggested two solutions, but both appear to have issues. Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case. Furthermore, after commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk. Regarding the bug fixed by commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), it has been resolved after commit 0460253913e5 (\"NFSv4: nfs4_do_open() is incorrectly triggering state recovery\") because all slots are drained before calling nfs4_do_reclaim, which prevents concurrent stateid changes along this path. Also, nfs_delegation_claim_locks does not cause this concurrency either since when _nfs4_proc_setlk is called with NFS_DELEGATED_STATE, no RPC is sent, so nfs4_lock_done is not called. Therefore, nfs4_lock_delegation_recall from nfs_delegation_claim_locks is the first time the stateid is set.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72473", "url": "https://ubuntu.com/security/CVE-2026-72473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decouple req recycling from RPC completion rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer. Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off. The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry. Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied. Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected. Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released. The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74310", "url": "https://ubuntu.com/security/CVE-2026-74310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/net: complete zerocopy ubufs only once vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74345", "url": "https://ubuntu.com/security/CVE-2026-74345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix endpoint/socket association handling Disassociating a socket from an endpoint via siw_socket_disassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within. This fixes a: BUG: KASAN: slab-use-after-free in siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1053 drivers/infiniband/sw/siw/siw_cm.c:1075) which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74361", "url": "https://ubuntu.com/security/CVE-2026-74361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: fix FDP fdpcidx bounds check The fdpcidx bounds check sets n = NUMFDPC + 1 but used > instead of >=, incorrectly accepting fdp_idx when it equals n (i.e. NUMFDPC + 1).", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74401", "url": "https://ubuntu.com/security/CVE-2026-74401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix add msg handle in send_queue ordered In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as \"before(mh->seq, seq)\" will stop to check for older sequence numbers that are ordered in the tail of \"node->send_queue\". The side effects of not having it correct ordered regarding \"before(mh->seq, seq)\" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74406", "url": "https://ubuntu.com/security/CVE-2026-74406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74428", "url": "https://ubuntu.com/security/CVE-2026-74428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix double unlock in rxrpc_recvmsg() Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74433", "url": "https://ubuntu.com/security/CVE-2026-74433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix UAF in rxgk_issue_challenge() Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74434", "url": "https://ubuntu.com/security/CVE-2026-74434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Don't move a peeked OOB message onto the pending queue rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so only unlink it from recvmsg_oobq and then move it onto pending_oobq or free it when the message is actually consumed.", "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-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-74439", "url": "https://ubuntu.com/security/CVE-2026-74439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clear Present bit before tearing down scalable-mode context entry device_pasid_table_teardown() zeroes the 128-bit scalable-mode context entry with context_clear_entry() while the Present bit is still set. This creates a window where the hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behavior or spurious faults. The context-cache invalidation is issued only after the entry has been zeroed, and intel_pasid_free_table() then frees the PASID directory pages, so the IOMMU can keep walking a stale Present=1 entry that points at freed memory. While x86 provides strong write ordering, the compiler may reorder the two 64-bit writes to the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Commit c1e4f1dccbe9d (\"iommu/vt-d: Clear Present bit before tearing down context entry\") fixed this exact pattern in domain_context_clear_one() and the copied-context path, but device_pasid_table_teardown() was not converted. Align it with the \"Guidance to Software for Invalidations\" in the VT-d spec, Section 6.5.3.3, using the same ownership handshake as the sibling fix: clear only the Present bit, flush it to the IOMMU, perform the context-cache invalidation, and only then zero the rest of the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" } ], "log": [ "", " * noble/linux-riscv-7.0: 7.0.0-38.38.1~24.04.1 -proposed tracker (LP: #2165483)", "", " [ Ubuntu-riscv: 7.0.0-38.38.1 ]", "", " * resolute/linux-riscv: 7.0.0-38.38.1 -proposed tracker (LP: #2165484)", " * resolute: llvm-21-dev build-depends breaks cross-builds (LP: #2165407)", " - [Packaging] Fix cross-builds", " * Zfhmin/Zvfhmin not reported when Zfh/Zvfh are present (LP: #2166547)", " - riscv: report Zfhmin/Zvfhmin when Zfh/Zvfh are present", " [ Ubuntu: 7.0.0-38.38 ]", " * resolute/linux: 7.0.0-38.38 -proposed tracker (LP: #2166443)", " * linux: dtbs_install fails on Resolute builders due to uutils install(1)", " EEXIST race under parallel make (LP: #2166356)", " - SAUCE: [Packaging] Serialise dtbs_install to work around uutils", " install(1) race", " * #510/p sleepable raw tracepoint reject from test_verifier in ubuntu_bpf", " failed with resolute (7.0.0-33.33) generic amd64 (LP: #2165872)", " - SAUCE: Revert \"bpf: Verifier support for sleepable tracepoint programs\"", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189)", " - 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", " - seqlock: Allow UBSAN_ALIGNMENT to fail optimizing", " - KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN", " - crypto: tegra - Don't touch bo refcount in host1x bo pin/unpin", " - xprtrdma: Clear receive-side ownership pointers on release", " - Input: ims-pcu - fix logic error in packet reset", " - fuse: fix writeback array overflow when max_pages is one", " - arm64: tegra: Remove fallback compatible for GPCDMA", " - arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234", " - xfrm: propagate -EINPROGRESS from validate_xmit_xfrm()", " - mtd: mtdswap: remove debugfs stats file on teardown", " - mtd: nand: mtk-ecc: stop on ECC idle timeouts", " - btrfs: fallback to transaction csum tree on a commit root csum miss", " - RDMA/cma: Fix hardware address comparison length in netevent callback", " - RDMA/irdma: Remove redundant legacy_mode checks", " - RDMA/erdma: initialize ret for empty receive WR lists", " - RDMA/mana_ib: initialize err for empty send 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: cfg80211: derive S1G beacon TSF from S1G fields", " - wifi: nl80211: validate nested MBSSID IE blobs", " - wifi: nl80211: constrain MBSSID TX link ID range", " - wifi: cfg80211: validate PMSR measurement type data", " - wifi: cfg80211: reject unsupported PMSR FTM location requests", " - wifi: mac80211: avoid non-S1G AID fallback for S1G assoc", " - ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on", " start/stop", " - ASoC: amd: ps: disable MSI on resume in ACP PCI driver", " - ASoC: amd: ps: fix wrong ACP version string in pci_request_regions()", " - ASoC: amd: ps: replace bitwise OR with logical OR in IRQ return check", " - 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", " - cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq", " - udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()", " - ata: sata_dwc_460ex: use platform_get_irq()", " - ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending", " interrupts", " - accel/ivpu: Fix wrong register read in LNL failure diagnostics", " - ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC", " - drm/i915/gt: use correct selftest config symbol", " - powerpc/85xx: Add fsl,ifc to common device ids", " - powerpc/time: Prepare to stop elapsing in dynticks-idle", " - powerpc/vtime: Initialize starttime at boot for native accounting", " - drm/panthor: Check debugfs GEM lock initialization", " - riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()", " - can: j1939: fix lockless local-destination check", " - drm/xe/wopcm: fix WOPCM size for LNL+", " - drm/i915/wm: clear the plane ddb_y entries on plane disable", " - 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: gadget: fsl-udc: fix dev_printk() device", " - 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", " - SAUCE: Revert \"usb: typec: ucsi: Detect and skip duplicate altmodes from", " buggy firmware\"", " - usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware", " - wifi: mwifiex: fix freeze for 60 seconds caused by request_firmware", " - RISC-V: KVM: Serialize virtual interrupt pending state updates", " - Revert \"drm/amd/display: Add missing kdoc for ALLM parameters\"", " - usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits", " - selftests/bpf: Adjust verifier_map_ptr for the map's excl field", " - selftests/bpf: Keep verifier_map_ptr exercising ops pointer access", " - 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", " - btrfs: fix u32 to s64 type conversion in dirty_metadata_bytes accounting", " - ASoC: sun4i-codec: Set quirks.playback_only for H616 codec", " - 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: fix pointer arithmetic in iwl_add_mcc_to_tas_block_list", " - wifi: iwlwifi: validate payload length in iwl_pnvm_complete_fn", " - wifi: iwlwifi: mvm: fix read in wake packet notification handler", " - usb: atm: ueagle-atm: reject descriptors that confuse probe and", " disconnect", " - drivers/virt: pkvm: Fix end calculation in mmio_guard_ioremap_hook()", " - 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", " - selftests/net: ovpn: fix getaddrinfo memory leak in ovpn_parse_remote()", " - ovpn: use monotonic clock for peer keepalive timeouts", " - regulator: mt6358: use regmap helper to read fixed LDO calibration", " - net: phy: marvell: fix return code", " - netlink: specs: rt-link: convert bridge port flag attributes to u8", " - gtp: parse extension headers before reading inner protocol", " - vhost-net: fix TX stall when vhost owns virtio-net header", " - wifi: mac80211: recalculate TIM when a station enters power save", " - pds_core: reject component parameter in legacy firmware update", " - arm64: Correct value returned by ESR_ELx_FSC_ADDRSZ_nL()", " - amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN", " - soreuseport: Clear sk_reuseport_cb before failure in sk_clone().", " - net: Call net_enable_timestamp() before failure in sk_clone().", " - 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", " - selftests: af_unix: add USER_NS config", " - selftests: openvswitch: add config file", " - selftests: ovpn: add IPV6 and VETH configs", " - selftests: ovpn: increase timeout", " - selftests: drv-net: increase timeout", " - ppp: don't store tx skb in the fastpath", " - ppp: annotate concurrent dev->stats accesses", " - ovl: fix trusted xattr escape prefix matching", " - drm/panel: s6e3ha8: fix unmet dependency on DRM_DISPLAY_HELPER", " - 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", " - drm/xe/i2c: Allow per domain unique id", " - iomap: correct the range of a partial dirty clear", " - drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem", " - net: stmmac: xgmac: fix l4 filter port overwrite on register update", " - 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: annotate data races in ppp_generic", " - hinic: remove unused ethtool RSS user configuration buffers", " - raw: annotate lockless match fields in raw_v4_match()", " - 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", " - octeontx2-pf: tc: fix egress ratelimiting", " - net: ipv6: fix dif and sdif mismatch in raw6_icmp_error", " - ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV", " - ice: fix LAG recipe to profile association", " - ipv6: Change allocation flags to match rcu_read_lock section", " requirements", " - ptp: netc: explicitly clear TMR_OFF during initialization", " - mctp: check register_netdevice_notifier() error in mctp_device_init()", " - net: airoha: fix ETS channel derivation in airoha_tc_setup_qdisc_ets()", " - drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay", " - drm: renesas: rzg2l_mipi_dsi: Move rzg2l_mipi_dsi_set_display_timing()", " - drm/tidss: Fix missing drm_bridge_add() call", " - 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/sysfb: Do not page-align visible size of the framebuffer", " - drm/sysfb: Avoid truncating maximum stride", " - drm/amdgpu/gfx9: Fix Ring and IB test fail after mode2", " - drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT", " - drm/sysfb: Return errno code from drm_sysfb_get_visible_size()", " - drm/displayid: fix Tiled Display Topology ID size", " - drm/nouveau/acr: fix missing nvkm_done() in error path of", " nvkm_acr_oneinit()", " - drm/radeon: fix r100_copy_blit for large BOs", " - drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked binds", " - drm/amdkfd: Use kvcalloc to allocate arrays", " - drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips", " - drm/i915/hdcp: require monotonically increasing seq_num_v", " - drm/amd/amdgpu: disable ASPM on VI if pcie dpm is disabled", " - drm/amd/pm: fix smu14 power limit range calculation", " - drm/gfx10: Program DB_RING_CONTROL", " - drm/virtio: Don't detach GEM from a non-created context", " - drm/panthor: return error on truncated firmware", " - drm/amdgpu: Fix VFCT bus number matching with soft filter", " - drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)", " - drm/amd/display: consolidate DCN vblank/flip handling onto", " vupdate_no_lock", " - drm/amd/display: Force PWM backlight on Lenovo Legion 5 15ARH05", " - drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge", " - drm/amd/display: Fix flip-done timeouts on mode1 reset", " - drm/amd/display: Fix missing DCE check in", " dm_gpureset_toggle_interrupts()", " - drm/v3d: Reach the GMP through the hub registers on V3D 7.x", " - 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: imx219: Fix maximum frame length in lines", " - media: iris: Fix use IRQF_NO_AUTOEN when requesting the IRQ", " - media: marvell-cam: fix missing pci_disable_device() on remove", " - media: nuvoton: npcm-video: fix error handling in npcm_video_init()", " - 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: qcom: camss: Fix RDI streaming for CSID 680", " - media: qcom: camss: Fix RDI streaming for CSID GEN2", " - media: qcom: camss: Fix RDI streaming for CSID GEN3", " - media: rzg2l-cru: Skip ICnMC configuration when ICnSVC is used", " - media: synopsys: hdmirx: Fix HPD lane hold time", " - 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: v4l2-subdev: Fail {enable,disable}_streams and s_streaming nicely", " - media: vb2: use ssize_t for vb2_read/vb2_write", " - media: verisilicon: Export only needed pixels formats", " - media: vidtv: fix reference leak on failed device registration", " - media: vimc: fix reference leak on failed device registration", " - media: vpif_capture: fix OF node reference imbalance", " - ALSA: hda/realtek: Fix speakers on Lunnen Ground 14", " - ALSA: hda: codecs: hdmi: disable keep-alive before audio format change", " - wifi: brcmfmac: set F2 blocksize to 256 for BCM43752", " - wifi: ath11k: fix refcount leak in ath11k_ahb_fw_resources_init()", " - staging: rtl8723bs: fix inverted HT40 secondary channel offset", " - platform/loongarch: laptop: Explicitly reset bl_powered state when", " suspend", " - rust_binder: only print failure if error has source", " - rust: time: fix as_micros_ceil() to round correctly for negative Delta", " - rust: allow `clippy::unwrap_or_default` globally", " - objtool/rust: add one more `noreturn` Rust function for Rust 1.99.0", " - LoongArch: Fix address space mismatch in kexec command line lookup", " - LoongArch: Fix oops during single-step debugging", " - LoongArch: Move jump_label_init() before parse_early_param()", " - LoongArch: Retrieve CPU package ID from PPTT when available", " - x86/boot/compressed: Disable jump tables", " - uio_hv_generic: Bind to FCopy device by default", " - serial: sc16is7xx: implement gpio get_direction() callback", " - selftests: ntsync: correct CONFIG_NTSYNC name", " - tracing: Fix context switch counter truncation", " - 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()", " - mptcp: decrement subflows counter on failed passive join", " - mptcp: only set DATA_FIN when a mapping is present", " - mm/kmemleak: fix checksum computation for per-cpu objects", " - mm/huge_memory: set PG_has_hwpoisoned only after new folio head is", " established", " - ceph: fix refcount leak in ceph_readdir()", " - ceph: fix writeback_count leak in write_folio_nounlock()", " - ASoC: fsl: imx-card: Skip sysclk reset for active DAIs in shutdown", " - ASoC: fsl_sai: Fix spurious BCLK on resume by clearing BYP", " - io_uring/rw: fix missing ERESTARTSYS conversion in read paths", " - iommu/vt-d: Disallow SVA if page walk is not coherent", " - net: stmmac: intel: skip SerDes reconfig when rate is unchanged", " - net: pcs: xpcs: fix SGMII state reading", " - proc: Fix broken error paths for namespace links", " - s390/ptff: Export ptff_function_mask[]", " - smb: client: handle STATUS_STOPPED_ON_SYMLINK responses without a", " symlink target", " - ice: use READ_ONCE() to access cached PHC time", " - ovpn: hold peer before scheduling keepalive work", " - vsock/virtio: collapse receive queue under memory pressure", " - watchdog: s32g_wdt: remove incorrect options in watchdog_info struct", " - drm/amd/pm: fix amdgpu_pm_info power display units", " - drm/amd/pm: make pp_features read-only when scpm is enabled", " - drm/amdgpu/jpeg: fix jpeg_v4_0_3_is_idle detection", " - drm/amdgpu/jpeg: fix jpeg_v5_0_1_is_idle detection", " - drm/amdgpu/soc24: reset dGPU if suspend got aborted", " - drm/amdgpu: fix resource leak on ACP reset timeout", " - drm/amd/pm: fix smu13 power limit range calculation", " - drm/amdgpu: fix check in amdgpu_hmm_invalidate_gfx", " - drm/xe/uapi: Reject coh_none PAT index for CPU_ADDR_MIRROR", " - net: qrtr: ns: Raise node count limit to 512", " - drm/amd/display: Fix DTB DTO updates breaking live pixel rate sources", " - audit: widen ino fields to u64", " - audit: use 'unsigned int' instead of 'unsigned'", " - xfs: don't replace the wrong part of the cow fork", " - netfilter: nf_tables: remove register tracking infrastructure", " - drm: drop lib from header search path.", " - SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlists", " - SUNRPC: Return an error from xdr_buf_to_bvec() on overflow", " - SAUCE: Revert \"mm/sparse-vmemmap: fix vmemmap accounting underflow\"", " - mm/sparse-vmemmap: fix vmemmap accounting underflow", " - mmc: vub300: rename probe error labels", " - net: mana: Optimize irq affinity for low vcpu configs", " - bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c", " - bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()", " - pmdomain: imx93-blk-ctrl: convert to devm_* only", " - rust: allow `suspicious_runtime_symbol_definitions` lint for Rust >=", " 1.98", " - rust: device: avoid trailing ; in printing macros", " - sched_ext: Skip ops.set_weight() for disabled tasks", " - sched_ext: Annotate ksyncs with __rcu in alloc/free_kick_syncs()", " - reset: spacemit: k3: fix USB2 ahb reset", " - wifi: cfg80211: reject empty PMSR peer lists", " - ASoC: amd: acp: Fix linker error with SDCA quirks", " - [Config] Adjust config SND_SOC_ACPI_AMD_SDCA_QUIRKS", " - sched_ext: Enable tick for finite slices on nohz_full", " - Bluetooth: mgmt: Translate HCI reason in Device Disconnected event", " - riscv: Gate FUNCTION_ALIGNMENT_4B on DYNAMIC_FTRACE", " - spi: cadence-quadspi: Fix indirect write timeout when DMA read mode is", " enabled", " - drm/xe: Assign queue name in time for drm_sched_init", " - drm/xe: add WQ_PERCPU to alloc_workqueue users", " - selftests: netconsole: only restore MAC when it changed on resume", " - wifi: ath10k: fix skb leak on incomplete msdu during rx pop", " - wifi: ath12k: Fix low MLO RX throughput on WCN7850", " - iommu/amd: Fix nested domain leak", " - arm_mpam: Fix software reset values of MPAMCFG_PRI", " - arm_mpam: Fix MPAMCFG_MBW_PBM register setting", " - hwmon: Drop unused i2c driver_data", " - hwmon: Use named initializers for arrays of i2c_device_data", " - hwmon: (pmbus/max34440): add support adpm12250", " - hwmon: (pmbus/max34440) block unsupported VIN and IIN limit registers", " - drm/i915/backlight: Remove DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check for", " DPCD backlight", " - selftests/net: Fix tun IPv6 test addresses to avoid 6to4 range", " - geneve: fix hint header definition wrt endianness", " - geneve: ensure the skb is writable before fixing its headers", " - accel: ethosu: Handle U85 internal chaining buffer", " - selftests: drv-net: convert so_txtime to drv-net", " - cifs: prevent readdir from changing file size due to stale directory", " metadata", " - wifi: mt76: fix airoha_npu dependency tracking", " - [Config] Fix config dependencies for MT76_NPU", " - drm/panel: ilitek-ili9882t: fix unmet dependency for", " DRM_PANEL_ILITEK_ILI9882T", " - iomap: fix incorrect did_zero setting in iomap_zero_iter()", " - mpls: Set rt->rt_nhn just before returning from mpls_nh_build_multi().", " - LoongArch: BPF: Zero-extend signed ALU32 div/mod results", " - bnge/bng_re: fix ring ID widths", " - pidfs: make pidfs_ino_lock static", " - LoongArch: BPF: Fix memory leak in bpf_jit_free()", " - drm/exynos: fbdev: Remove offset into screen_buffer", " - drm/tegra: fbdev: Remove offset into framebuffer memory", " - drm/i915/cdclk: Fix up CDCLK_FREQ_DECIMAL without a full PLL re-enable", " - drm/amd/pm: re-enable MC access after PrepareMp1ForUnload on SMU V15", " APUs", " - bitmap: add test_zero_nbits()", " - drm/xe: Add compact-PT and addr mask handling for page reclaim", " - drm/amd/display: Restore periodic detection for DCN35", " - drm/amdgpu: Respect placement requirements in amdgpu_gtt_mgr functions", " - drm/amdkfd: Use exclusive bounds for SVM split alignment checks", " - drm/i915/mtl+: Enable PPS before PLL", " - drm/xe/oa: Fix offset alignment for MERT WHITELIST_OA_MERT_MMIO_TRG", " - drm/xe/nvm: fix writable override for CRI", " - drm/amdgpu: Check for multiplication overflow in checkpoint stack size", " - drm/amdkfd: Guard m->cp_hqd_eop_control setting by", " q->eop_ring_buffer_size", " - drm/amdkfd: free MQD managers on DQM init failures", " - drm/amd/display: set MSA MISC1 bit 6 when using VSC SDP for DCE 11.x", " - drm/amdgpu: add the doorbell index input for suspending userq", " - drm/amdgpu: remove deadlocks from amdgpu_userq_pre_reset", " - drm/amd: Create a device link between APU display and XHCI devices", " - drm/pagemap: Clear driver-provided PFNs from migration PFN array", " - mm: add gpu active/reclaim per-node stat counters (v2)", " - drm/ttm: use gpu mm stats to track gpu memory allocations. (v4)", " - drm/ttm: Fix GPU MM stats during pool shrinking", " - drm/ttm/pool: back up at native page order", " - drm/gpusvm: Zero HMM PFNs before scanning ranges", " - media: mali-c55: Add missing of_reserved_mem_device_release()", " - media: mali-c55: Disable pm_runtime on probe error", " - media: mali-c55: Power-off the peripheral in remove()", " - media: qcom: camss: Fix RDI streaming for CSID 340", " - media: rzv2h-ivc: Wait for frame end in stop_streaming", " - media: ti: vpe: Fix fwnode_handle leak in vip_probe_complete()", " - media: ti: vpe: Fix the error code of devm_request_irq()", " - media: uapi: rkisp: Correct name version enum", " - wifi: mt76: restrict NPU/PPE active checks to MMIO devices", " - LoongArch: Fix build errors due to wrong instructions for 32BIT", " - LoongArch: Increase TASK_STRUCT_OFFSET up to 2040 for 32BIT", " - firmware: stratix10-svc: fix teardown order in remove to prevent race", " - firmware: stratix10-svc: handle NO_RESPONSE in async poll", " - tracing: perf: Fix stale head for perf syscall tracing", " - 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\"", " - selftests: mptcp: userspace_pm: fix undefined variable port", " - m68k: avoid -Wunused-but-set-parameter in clear_user_page()", " - mm/memory-failure: trace: change memory_failure_event to ras subsystem", " - mm/slub: fix lost local objects when bulk remote free batch fills", " - mm/slab: fix a memory leak due to bootstrapping sheaves twice", " - drm/amdgpu: rework userq fence driver alloc/destroy", " - drm/amdgpu: rework userq fence signal processing", " - drm/amdgpu/gfx11: fix EOP interrupt routing for KQ and userq", " - drm/amdgpu/gfx12: fix EOP interrupt routing for KQ and userq", " - drm/amdgpu/mes11: set doorbell offset for suspending userq", " - selftests: drv-net: add missing kconfig for psp.py", " - mm/sparse-vmemmap: pass @pgmap argument to memory deactivation paths", " - mm/sparse-vmemmap: fix DAX vmemmap accounting with optimization", " - selftests: drv-net: cope with slow env in so_txtime.py test", " - selftests: drv-net: so_txtime: relax variance bounds", " - cifs: fix time_last_write stamp placement in setattr/truncate paths", " - cifs: consolidate time_last_write stamp into _cifsFileInfo_put()", " - Upstream stable to v6.18.41, v6.18.42, v6.18.43, v7.1.6, v7.1.7", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68480", " - x86/bugs: Make Safe-RET robust against interrupt injection", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68105", " - drm/amdgpu: Fix kernel panic during driver load failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68109", " - drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68114", " - drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68431", " - ksmbd: validate minimum PDU size for transform requests", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68138", " - net/sched: serialize qdisc_rtab_list against concurrent get/put", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68082", " - libceph: fix two unsafe bare decodes in decode_lockers()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68159", " - libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68163", " - mm/page_vma_mapped: fix device-private PMD handling", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68166", " - userfaultfd: prevent registration of special VMAs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68170", " - mptcp: fix stale skb->sk reference on subflow close", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68177", " - tracing: Delay module ref count for \"enable_event\" trigger", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68191", " - wifi: ath12k: fix NULL pointer dereference in rhash table destroy", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64586", " - wifi: brcmfmac: drain bus_reset work on device removal", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68208", " - media: ti: vpe: Fix the error code of devm_kzalloc() in", " vip_probe_slice()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68224", " - media: mali-c55: Fix possible ERR_PTR in enable_streams", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68237", " - drm/amdgpu/userq: fix indefinite fence wait during GPU reset", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68240", " - drm/gpusvm: publish dpagemap early to avoid device mapping leak on error", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68242", " - drm/i915/gt: Fix NULL deref on sched_engine alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68254", " - drm/i915/vrr: require valid min/max vfreq for VRR", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68436", " - drm/amd/display: use kvzalloc to allocate struct dc", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68447", " - drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68264", " - drm/xe/pt: Reset current_op in xe_pt_update_ops_init()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68265", " - drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68267", " - drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68273", " - drm/amdgpu: Fix context pstate override handling", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68274", " - drm/xe/guc: Fix buffer overflow in steered register list allocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68283", " - tracing: Fix use-after-free freeing trigger private data", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68286", " - drop_monitor: perform u64_stats updates under IRQ-disabled section", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68287", " - drop_monitor: fix size calculations for 64-bit attributes", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68288", " - net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68289", " - tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68291", " - idpf: fix max_vport related crash on allocation error during init", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68303", " - drm/vc4: hvs/v3d: Fix null dereference in unbind", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68312", " - cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain", " paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68316", " - accel: ethosu: Fix element size accounting for cmd stream validation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68322", " - rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68440", " - net: txgbe: fix heap overflow when reading module EEPROM", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68323", " - tipc: serialize udp bearer replicast list updates", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68441", " - net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68337", " - bpf: Reject redirect helpers without a bpf_net_context", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68345", " - arm_mpam: guard MBWU state before adding it to garbage", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68347", " - iommu/amd: Fix IRQ unsafe locking in gdom allocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68375", " - bnxt_en: Handle partially initialized auxiliary devices", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68382", " - drm/xe/guc: Hold device ref until queue teardown completes", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68383", " - drm/xe/guc: Keep scheduler timeline name alive", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68390", " - Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68399", " - bpf: Fix UAF in sock clone early bailouts", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68404", " - wifi: cfg80211: use wiphy work for socket owner autodisconnect", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64581", " - xfrm: fix sk_dst_cache double-free in xfrm_user_policy()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68093", " - KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision", " after hotplug", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68367", " - usb: gadget: f_tcm: synchronize delayed set_alt with teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68164", " - mm/damon/core: disallow overlapping input ranges for damon_set_regions()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68165", " - mm/damon/core: validate ranges in damon_set_regions()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68095", " - fuse-uring: fix race between registration and connection abortion", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68096", " - audit: fix recursive locking deadlock in audit_dupe_exe()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68147", " - fscrypt: Avoid dynamic allocation in fscrypt_get_devices()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68097", " - ksmbd: validate ACE size against SID sub-authorities", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68098", " - ksmbd: bound DACL dedup walk to copied ACEs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68099", " - ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68100", " - ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68173", " - ublk: wait on ublk_dev_ready() instead of ub->completion", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68104", " - drm/amdgpu: invoke pm_genpd_remove() before freeing genpd", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68106", " - drm/amdgpu: fix division by zero with invalid uvd dimensions", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68429", " - drm/dp_mst: Handle torn-down topology gracefully in", " drm_dp_mst_topology_queue_probe()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68107", " - drm/amdgpu/vcn4: avoid rereading IB param length", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68108", " - drm/amdgpu/vce: fix integer overflow in image size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68110", " - drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68111", " - drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68112", " - drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68430", " - drm/amdgpu/gfx8: drop unecessary BUG_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68113", " - drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68246", " - drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68115", " - drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68116", " - vxlan: mdb: Fix source list corruption on a failed replace", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68117", " - tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68118", " - tcp: challenge ACK for non-exact RST in SYN-RECEIVED", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68119", " - tcp: initialize standalone TCP-AO response padding", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68120", " - rtase: Workaround for TX hang caused by hardware packet parsing", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68121", " - pppoe: reload header pointer after dev_hard_header()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68122", " - ovpn: fix peer refcount leak in TCP error paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68123", " - openvswitch: fix GSO userspace truncation underflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68124", " - mctp: serial: handle zero-length frames to prevent rx buffer overflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68125", " - mac802154: llsec: reject frames shorter than the authentication tag", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68126", " - mac802154: hold an interface reference across the scan worker", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68127", " - ila: reload IPv6 header after pskb_may_pull in checksum adjust", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68128", " - ice: reject out-of-range ptype in ice_parser_profile_init", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68129", " - gve: fix Rx queue stall on alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68130", " - ksmbd: defer destroy_previous_session() until after NTLM authentication", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68131", " - rbd: Reset positive result codes to zero in object map update path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68132", " - super: fix emergency thaw deadlock on frozen block devices", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68133", " - ice: fix PTP Call Trace during PTP release", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68134", " - ptp: ptp_s390: Add missing facility check", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68135", " - net: hip04: fix RX buffer leak on build_skb failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68136", " - net: gro: fix double aggregation of flush-marked skbs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68137", " - net/x25: fix use-after-free in x25_kill_by_neigh()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68139", " - net/mlx5e: Use sender devcom for MPV master-up", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68140", " - net/iucv: fix use-after-free of a severed iucv_path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68141", " - net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68142", " - geneve: require CAP_NET_ADMIN in the device netns for changelink", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68143", " - net: slip: serialize receive against buffer reallocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68432", " - vxlan: require CAP_NET_ADMIN in the device netns for changelink", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68144", " - phonet: pep: fix use-after-free in pep_get_sb()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68145", " - iomap: fix out-of-bounds bitmap_set() with zero-length range", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68146", " - ftrace: Add global mutex to serialize trace_parser access", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68148", " - fscrypt: Add missing superblock check in find_or_insert_direct_key()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68149", " - fs: preserve ACL_DONT_CACHE state in forget_cached_acl()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68150", " - fs/super: fix emergency thaw double-unlock of s_umount", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68151", " - binfmt_elf_fdpic: only honour the first PT_INTERP", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68152", " - amt: fix use-after-free in AMT delayed works", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68153", " - libceph: remove debugfs files before client teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68154", " - libceph: reject zero bucket types in crush_decode", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68155", " - libceph: Reject monmaps advertising zero monitors", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68156", " - libceph: refresh auth->authorizer_buf{,_len} after authorizer update", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68157", " - libceph: guard missing CRUSH type name lookup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68158", " - libceph: Fix multiplication overflow in decode_new_up_state_weight()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68433", " - libceph: bound get_version reply decode to front len", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68160", " - ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68161", " - sctp: close UDP tunnel sockets during netns teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68162", " - sctp: avoid auth_enable sysctl UAF during netns teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64564", " - sctp: don't free the ASCONF's own transport in DEL-IP processing", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68168", " - afs: Fix afs_edit_dir_remove() to get, not find, block 0", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68169", " - mptcp: pm: userspace: fix use-after-free in get_local_id", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68172", " - arm64: make huge_ptep_get handled unaligned addresses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68174", " - tracing: Fix union collision of module and refcnt for dynamic events", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68175", " - tracing: Fix resource leak on mmiotrace trace_pipe close", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68176", " - tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68178", " - misc: nsm: pin the module while the device is open", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68179", " - misc: nsm: only unlock nsm_dev on post-lock error paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68180", " - intel_th: fix MSC output device reference leak", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68181", " - mei: bus: access mei_device under device_lock on cleanup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68434", " - serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR", " platforms", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68182", " - comedi: comedi_parport: deal with premature interrupt", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68183", " - firmware: stratix10-svc: fix memory leaks and list corruption bugs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64563", " - rhashtable: clear stale iter->p on table restart", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68184", " - cdrom: fix stack out-of-bounds read in CDROMVOLCTRL", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68186", " - binfmt_misc: set have_execfd only once the interpreter is opened", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68187", " - exec: fix unsigned loop counter wrap in transfer_args_to_stack()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68188", " - Bluetooth: RFCOMM: Fix session UAF in set_termios", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68189", " - Bluetooth: hci_sync: Protect UUID list traversal", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68190", " - staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68192", " - wifi: brcmfmac: make release_scratchbuffers idempotent", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68193", " - wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68194", " - wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68195", " - wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68196", " - wifi: wilc1000: validate assoc response length before subtracting header", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68197", " - wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-", " oper", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68198", " - wifi: ath6kl: fix use-after-free in aggr_reset_state()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68199", " - wifi: ath6kl: fix OOB access from firmware ADDBA window size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68200", " - ALSA: timer: don't re-enter an instance callback that is still running", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68201", " - ALSA: timer: drain a slave's callback before its master detaches it", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68202", " - ALSA: seq: close a re-opened queue timer in the destructor", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68203", " - media: vivid: fix cleanup bugs in vivid_init()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68204", " - media: vivid: check for vb2_is_busy() when toggling caps", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68205", " - media: v4l2-fwnode: Fix subdev owner overwritten in", " v4l2_async_register_subdev_sensor()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68206", " - media: v4l2-ctrls: validate HEVC active reference counts", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68207", " - media: ti: vpe: unwind v4l2 device registration on probe error", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68209", " - media: sun4i-csi: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68210", " - media: stm32: dcmi: unregister notifier on probe failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68211", " - media: stm32-dcmipp: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68212", " - media: saa7134: Fix a possible memory leak in saa7134_video_init1", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68213", " - media: rtl2832_sdr: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68214", " - media: rtl2832: fix use-after-free in rtl2832_remove()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68215", " - media: radio-si476x: Unregister v4l2_device on probe failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68216", " - media: pwc: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68217", " - media: pwc: Drain fill_buf on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68218", " - media: pci: dm1105: Free allocated workqueue", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68219", " - media: nxp: imx8-isi: Fix potential out-of-bounds issues", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68220", " - media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and", " pipe", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68221", " - media: nuvoton: npcm-video: fix memory leaks in probe and remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68222", " - media: msi2500: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68223", " - media: meson: vdec: Fix memory leak in error path of vdec_open", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68225", " - media: i2c: alvium: fix critical pointer access in alvium_ctrl_init", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68226", " - media: cx23885: add ioremap return check and cleanup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68227", " - media: cx231xx: fix devres lifetime", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68228", " - media: chips-media: wave5: Move src_buf Removal to finish_encode", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68229", " - media: cedrus: skip invalid H.264 reference list entries", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68230", " - media: amlogic-c3: Add validations for ae and awb config", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68231", " - media: airspy: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68232", " - drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68445", " - drm/vc4: Prevent shader BO mappings from becoming writable", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68446", " - drm/vmwgfx: Validate vmw_surface_metadata::array_size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68233", " - drm/vc4: Shut down BO cache timer before teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68234", " - drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68235", " - drm/amd/display: dce100: skip non-DP stream encoders for DP MST", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68236", " - drm/amd/display: set new_stream to NULL after release", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68238", " - drm/amdgpu: Release VFCT ACPI table reference", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68239", " - drm/ttm: Account for NULL and handle pages in ttm_pool_backup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68241", " - drm/i915/mst: limit DP MST ESI service loop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68243", " - drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68244", " - drm/i915/gem: Do not leak siblings[] on proto context error", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68245", " - drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68247", " - drm/i915/bios: range check LFP Data Block panel_type2", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68248", " - drm/i915: Return NULL on error in active_instance", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68249", " - drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68250", " - drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68251", " - drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68252", " - drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68253", " - drm/i915/hdcp: check streams[] bounds before overflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68255", " - drm/virtio: bound EDID block reads to the response buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68256", " - drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path", " leaks prev_sink reference", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68257", " - drm/amdkfd: fix 32-bit overflow in CWSR total size calculation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68258", " - drm/amdkfd: Check bounds on CRIU restore queue type and mqd size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68259", " - drm/amdkfd: Check bounds in allocate_event_notification_slot", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68260", " - drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68261", " - drm/imagination: fix error checking of pvr_vm_context_lookup()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68262", " - drm/imagination: Fix user array stride in pvr_set_uobj_array()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68263", " - drm/imagination: Fix double call to drm_sched_entity_fini()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68266", " - drm/xe: Hold a dma-buf reference for imported BOs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68268", " - drm/xe: Return error on non-migratable faults requiring devmem", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68269", " - drm/i915/gem: Add missing nospec on parallel submit slot", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68270", " - drm/sysfb: Avoid possible truncation with calculating visible size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68271", " - drm/nouveau: fix reversed error cleanup order in ucopy functions", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68272", " - drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68275", " - drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68276", " - drm/amdgpu/gfx: fix cleaner shader IB buffer overflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68277", " - drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68437", " - drm/imagination: Fit paired fragment job in the correct CCCB", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68278", " - drm/dp/mst: fix buffer overflows in sideband chunk accumulation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68279", " - drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68280", " - drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68281", " - drm/imagination: Count paired job fence as dependency in prepare_job()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68282", " - drm/rockchip: analogix_dp: Add missing error check for", " platform_get_resource()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68284", " - bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68290", " - rds: tcp: unregister sysctl before tearing down listen socket", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68292", " - ice: prevent tstamp ring allocation for non-PF VSI types", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68293", " - net/mlx5: Fix MCIA register buffer overflow on 32 dword reads", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68294", " - net: qrtr: restrict socket creation to the initial network namespace", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68296", " - net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64575", " - bpf: tcp: fix double sock release on batch realloc", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68297", " - tipc: fix u16 MTU truncation in media and bearer MTU validation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68298", " - drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68299", " - vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68300", " - sctp: auth: verify auth requirement when auth_chunk is NULL", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68301", " - net: hsr: fix memory leak on slave unregistration by removing synced", " VLANs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68302", " - amt: re-read skb header pointers after every pull", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68448", " - ovl: check access to copy_file_range source with src mounter creds", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68304", " - wifi: brcmfmac: fix 802.1X-SHA256 call trace warning", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68306", " - wifi: mt76: mt7996: fix possible NULL-pointer deref in", " mt7996_mcu_sta_bfer_eht()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68307", " - wifi: mt76: mt7925: fix crash in reset link replay", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68308", " - wifi: mt76: mt7996: check pointer returned by", " mt76_connac_get_he_phy_cap()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68439", " - wifi: mt76: mt7925: fix possible NULL-pointer deref in", " mt7925_mcu_bss_he_tlv()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68309", " - wifi: mt76: connac: fix possible NULL-pointer deref in", " mt76_connac_mcu_uni_bss_he_tlv()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68310", " - wifi: mt76: mt7915: guard HE capability lookups", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68311", " - wifi: mt76: mt7925: guard link STA in decap offload", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68313", " - tipc: fix infinite loop in __tipc_nl_compat_dumpit", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64576", " - nexthop: initialize extack in nh_res_bucket_migrate()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64577", " - gtp: check skb_pull_data() return in gtp1u_send_echo_resp()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68314", " - net: mctp i3c: clean up notifier and buses if driver register fails", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68315", " - sctp: validate stream count in sctp_process_strreset_inreq()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68317", " - pds_core: fix auxiliary device add/del races", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68318", " - pds_core: fix use-after-free on workqueue during remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68319", " - pds_core: fix deadlock between reset thread and remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68320", " - sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68321", " - net: txgbe: fix FDIR filter leak on remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68324", " - iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68325", " - iommu/amd: Bound the early ACPI HID map", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68326", " - wifi: mwifiex: bound uAP association event IEs to the event buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68327", " - wan: wanxl: Only reset hardware after BAR mapping", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68328", " - nfp: Check resource mutex allocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64574", " - wifi: mac80211: tear down new links on vif update error path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68329", " - iommu/amd: Wait for completion instead of returning early in", " iommu_completion_wait()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68330", " - net: airoha: Fix DMA direction for NPU mailbox buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68331", " - dpaa2-eth: put MAC endpoint device on disconnect", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68332", " - net: airoha: Fix potential use-after-free in airoha_ppe_deinit()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68333", " - dpaa2-switch: put MAC endpoint device on disconnect", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68334", " - rxrpc: fix io_thread race in rxrpc_wake_up_io_thread()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68335", " - rds: drop incoming messages that cross network namespace boundaries", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68336", " - bonding: fix devconf_all NULL dereference when IPv6 is disabled", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68338", " - net/packet: avoid fanout hook re-registration after unregister", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68339", " - Bluetooth: btusb: validate Realtek vendor event length", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68340", " - hwmon: occ: validate poll response sensor blocks", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68341", " - ovpn: fix use after free in unlock_ovpn()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68342", " - ovpn: avoid putting unrelated P2P peer on socket release", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68343", " - smb: client: validate DFS referral PathConsumed", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68346", " - ALSA: hda: cs35l41: validate and free ACPI mute object", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68348", " - ASoC: tas2781: bound firmware description string parsing", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68450", " - btrfs: free mapping node on duplicate reloc root insert", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68442", " - btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68349", " - wifi: carl9170: fix buffer overflow in rx_stream failover path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68350", " - wifi: carl9170: fix OOB read from off-by-two in TX status handler", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68351", " - wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68352", " - wifi: ath6kl: fix OOB read from firmware IE lengths in connect event", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68353", " - wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68354", " - firewire: net: Fix fragmented datagram reassembly", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68355", " - wifi: ath11k: fix potential buffer underflow in", " ath11k_hal_rx_msdu_list_get()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68356", " - watchdog: airoha: Prevent division by zero when clock frequency is zero", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68357", " - watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68358", " - hwmon: (nzxt-kraken3) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68359", " - hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68443", " - hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68360", " - hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68361", " - hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68362", " - wifi: ath11k: fix NULL pointer dereference in", " ath11k_hal_srng_access_begin", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68363", " - wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware", " request", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68365", " - USB: serial: io_edgeport: cap received transmit credits", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68366", " - usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64583", " - usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before", " teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68368", " - usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68369", " - usb: gadget: printer: fix infinite loop in printer_read()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64584", " - usb: gadget: f_midi: cancel pending IN work before freeing the midi", " object", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68370", " - usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68371", " - usb: musb: omap2430: Do not put borrowed of_node in probe", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68373", " - wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68374", " - usb: core: sysfs: add lock to bos_descriptors_read()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64569", " - mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68376", " - sctp: fix auth_hmacs array size in struct sctp_cookie", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68377", " - net/sched: act_tunnel_key: Defer dst_release to RCU callback", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68378", " - dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68379", " - tcp: fix TIME_WAIT socket reference leak on PSP policy failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68380", " - accel/amdxdna: Fix use-after-free of mm_struct in job scheduler", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64578", " - ksmbd: validate compound request size before reading StructureSize2", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68381", " - ksmbd: pin conn during async oplock break notification", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68384", " - drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68385", " - s390/checksum: Fix csum_partial() without vector facility", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68386", " - bpf, sockmap: Reject unhashed UDP sockets on sockmap update", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68387", " - can: raw: add locking for raw flags bitfield", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68388", " - smb/client: handle overlapping allocated ranges in fallocate", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68389", " - Bluetooth: hci_qca: Clear memdump state on invalid dump size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68391", " - Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68392", " - Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68393", " - Bluetooth: hci_sync: extend conn_hash lookup critical sections", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68394", " - Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64573", " - Bluetooth: qca: fix NVM tag length underflow in TLV parser", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68449", " - ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-", " scanning", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68395", " - ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is", " registered", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68396", " - scsi: core: wake eh reliably when using scsi_schedule_eh", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68397", " - net/iucv: take a reference on the socket found in afiucv_hs_rcv()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64572", " - ipv4: fib: free fib_alias with kfree_rcu() on insert error path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68398", " - ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68400", " - firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset", " calculation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68401", " - firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68402", " - wifi: cfg80211: bound element ID read when checking non-inheritance", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68403", " - wifi: brcmfmac: initialize SDIO data work before cleanup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68405", " - wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68406", " - wifi: cfg80211: validate PMSR FTM preamble range", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68407", " - wifi: nl80211: free RNR data on MBSSID mismatch", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68408", " - wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64571", " - wifi: p54: validate RX frame length in p54_rx_eeprom_readback()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68409", " - wifi: mac80211: defer link RX stats percpu free to RCU", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68410", " - wifi: libertas: fix memory leak in helper_firmware_cb()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64570", " - wifi: mac80211: fix fils_discovery double free on alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64568", " - wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68411", " - wifi: mac80211_hwsim: clamp virtio RX length before skb_put", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68412", " - wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68413", " - wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68414", " - wifi: cfg80211: cancel sched scan results work on unregister", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64579", " - xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64580", " - xfrm6: clear dst.dev on error to avoid double netdev_put in", " xfrm6_fill_dst()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64566", " - xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68415", " - xfrm: clear mode callbacks after failed mode setup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68416", " - mtd: fix double free and WARN_ON in add_mtd_device() error paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68417", " - RDMA/siw: publish QP after initialization", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68418", " - RDMA/irdma: Prevent user-triggered null deref on QP create", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68419", " - RDMA/irdma: Prevent rereg_mr for non-mem regions", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68420", " - xfrm: reject optional IPTFS templates in outbound policies", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68421", " - sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68444", " - firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68422", " - btrfs: fix root leak if its reloc root is unexpected in", " merge_reloc_roots()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64567", " - btrfs: reject free space cache with more entries than pages", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68425", " - IB/mad: Drop unmatched RMPP responses before reassembly", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68426", " - xfrm: fix stale skb->prev after async crypto steals a GSO segment", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64565", " - Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68427", " - gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68428", " - KVM: x86/mmu: Fix use-after-free on vendor module reload", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64562", " - KVM: nVMX: Hide shadow VMCS right after VMCLEAR", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64561", " - KVM: x86: Check for invalid/obsolete root *after* making MMU pages", " available", " * resolute: llvm-21-dev build-depends breaks cross-builds (LP: #2165407)", " - [Packaging] Fix cross-builds", " * Resolute Stable Update v6.18.40, v7.1.5 bugs (LP: #2165040)", " - accel/amdxdna: Allow forcing IOVA-based DMA via module parameter", " - SAUCE: bpf: Add missing NULL argument to zap_page_range_single", " - accel/amdxdna: Return ERR_PTR on dma_alloc_noncoherent failure", " - accel/amdxdna: Fix memory leak in amdxdna_iommu_alloc()", " * [SRU][HPE] Take Intel platform into account for old microcode checks", " (LP: #2161748)", " - x86/microcode: Refactor platform ID enumeration into a helper", " - x86/cpu: Add platform ID to CPU info structure", " - x86/cpu: Add platform ID to CPU matching structure", " - x86/microcode: Add platform mask to Intel microcode \"old\" list", " - x86/microcode: Do not access MSR_IA32_PLATFORM_ID when running as a", " guest", " * ice: E810 interface fails to initialize (ice_init_hw failed: -5) during", " NVM read (LP: #2163508)", " - ice: acquire NVM lock around each flash read", " * WWAN modem unresponsive after freeze on Dell systems with DW5826e", " (LP: #2163214)", " - platform/x86: dell-dw5826e: Add reset driver for DW5826e", " - platform/x86: dell-dw5826e: fix ACPI _DSM function index and bitmask", " usage", " - [Config] Add CONFIG_DELL_DW5826E_RESET=m", " * amdgpu panel self-refresh on dual-gpu laptops causes complete built-in", " panel freeze and severe system instability (LP: #2162904)", " - SAUCE: drm/amdgpu: Do not enter PSR if multiple displays are active", " * linux 7.0: dw9719 VCM never binds, disabling all IPU3 cameras (regression,", " fixed upstream) (LP: #2162045)", " - media: dw9719: Add back the I²C device id table", " * Fix TAS2783 SoundWire amp resume timeout >5s (LP: #2164967)", " - soundwire: Add a helper function to wait for device initialisation", " - ASoC: tas2783: Use new SoundWire enumeration helper", " - soundwire: Move wait for initialisation helper to header", " - ASoC: codecs: tas2783-sdw: Propagate regcache_sync() errors", " - ASoC: tas2783-sdw: drop stale regcache on uninitialized re-attach", " * Linux, Ubuntu, 24.04, System hangs for about 10 seconds when unplug", " external monitor cable on non TBT dock (LP: #2160082)", " - SAUCE: drm/i915/tc: Revert forced DP-alt connected workaround", " * Speakers not detected on HP systems with TI TAS2783 SoundWire amps", " (LP: #2164504)", " - ASoC: sdw_utils: Add missed component_name strings for TI amps", " * [TWL][Desktop] intel_dmc_wait_fw_load() merge to Ubuntu next release", " (LP: #2156316)", " - SAUCE: drm/i915/dmc: fix assert_dmc_loaded WARN during async firmware", " load", " * 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", " * Ethernet adapter unusable after suspend/resume on Advantech systems with", " Intel I226-V (LP: #2163375)", " - igc: fix netdev not re-attached after resume if interface is down", " * ice: fix stale -EBUSY on resume of Intel E810 (LP: #2162803)", " - ice: wait for reset completion in ice_resume()", " * idxd: crash-kernel NULL-pointer Oops in `destroy_workqueue()` breaks kdump", " on Intel DSA/IAA systems (LP: #2163062)", " - SAUCE: dmaengine: idxd: Do not call destroy_workqueue with null idxd->wq", " - SAUCE: dmaengine: idxd: fix duplicate memory frees on initialization", " error path.", " * [HP][ZBook Power 16 G11] Laptop freezed after upgrading the BIOS", " (LP: #2132119)", " - PCI/ASPM: Avoid L0s for Realtek RTS525A", " * Fix noise of audio output on more Dell QCx1255 models after reboot", " (LP: #2163293)", " - ALSA: hda/realtek - Add quirk for Dell Pro QC1255", " * Fix no audio input/output device on Dell WCL Slate platform with", " CirrusLogic audio solution (LP: #2160200)", " - ASoC: SDCA: fix the register to ctl value conversion for Q7.8 format", " - ASoC: SOF: ipc4-control: Use local copy of IPC message for sending", " * Fix no audio output and mute hotkey not working on HP ZBook 8 G2a", " (LP: #2158858)", " - ALSA: hda/realtek: Add inverted LED quirk for HP ZBook 8 G2a", " * Dock ethernet stops working after Thunderbolt dock unplug on Dell systems", " (LP: #2162704)", " - usb: core: port: Deattach Type-C connector on component unbind", " * USB-C alt mode dropped with false firmware bug warning on Dell systems", " (LP: #2162695)", " - Revert \"usb: typec: ucsi: Detect and skip duplicate altmodes from buggy", " firmware\"", " - Revert \"usb: typec: ucsi: Add duplicate detection to nvidia registration", " path\"", " - Revert \"usb: typec: ucsi: yoga_c630: Remove redundant duplicate altmode", " handling\"", " - usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware", " - usb: typec: ucsi: Add duplicate detection to nvidia registration path", " - usb: typec: ucsi: yoga_c630: Remove redundant duplicate altmode handling", " * Resolute update: upstream stable patchset 2026-08-20 (LP: #2164666)", " - crypto: algif_skcipher - force synchronous processing", " - crypto: sun4i-ss - Remove insecure and unused rng_alg", " - [Config] Remove unused CRYPTO_DEV_SUN4I_SS_PRNG", " - media: uvcvideo: Fix deadlock if uvc_status_stop is called from", " async_ctrl.work", " - bpf: Clear delta when clearing reg id for non-{add,sub} ops", " - selftests/bpf: Add tests for delta tracking when src_reg == dst_reg", " - selftests/bpf: Add tests for stale delta leaking through id reassignment", " - ALSA: hda/realtek: Add quirk for TongFang X6xx45xU", " - ALSA: hda: conexant: Remove mic bias threshold override", " - ALSA: hda: Fix cached processing coefficient verbs", " - ALSA: hda/realtek: Fix speakers on Legion Pro 7 16ARX8H with codec SSID", " 17aa:38a7", " - media: uvcvideo: Use hw timestaming if the clock buffer is full", " - media: uvcvideo: Avoid partial metadata buffers", " - media: uvcvideo: Fix buffer sequence in frame gaps", " - media: uvcvideo: Fix dev_sof filtering in hw timestamp", " - media: uvcvideo: Do not add clock samples with small sof delta", " - media: uvcvideo: Relax the constrains for interpolating the hw clock", " - 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: max310x: implement gpio_chip::get_direction()", " - serial: 8250_omap: clear rx_running on zero-length DMA completes", " - rxrpc: rxrpc_verify_data ensure rx_dec_buffer alloc", " - rxrpc: Fix socket notification race", " - rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)", " - rxrpc: Fix potential infinite loop in rxrpc_recvmsg()", " - rxrpc: Fix rxrpc_rotate_tx_rotate() to check there's something to rotate", " - rxrpc: Fix oob challenge leak in cleanup after notification failure", " - rxrpc: Fix ACKALL packet handling", " - rxrpc: Fix the reception of a reply packet before data transmission", " - rxrpc: Fix leak of connection from OOB challenge", " - afs: fix NULL pointer dereference in afs_get_tree()", " - afs: handle CB.InitCallBackState3 requests without a server record", " - afs: Fix uncancelled rxrpc OOB message handler", " - fbcon: fix NULL pointer dereference for a console without vc_data", " - fbcon: Use correct type for vc_resize() return value", " - openrisc: mm: Fix section mismatch between map_page and __set_fixmap", " - clocksource/drivers/sun5i: Handle error returns from", " devm_reset_control_get_optional_exclusive()", " - accel/amdxdna: Fix leak when pinning ubuf pages", " - drm/rockchip: dw_dp: Switch to drmm_kzalloc()", " - drm/rockchip: dw_dp: Fix null-ptr-deref in dw_dp_remove()", " - drm/rockchip: Test for imported buffers with drm_gem_is_imported()", " - drm/tidss: Drop extra drm_mode_config_reset() call", " - drm/gpusvm: Reject VMAs with VM_IO or VM_PFNMAP when creating SVM ranges", " - drm/gpuvm: Do not prepare NULL objects", " - 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", " - selftests/bpf: Fix off-by-one in bpf_cpumask_populate related selftest", " - dt-bindings: timer: Remove sifive,fine-ctr-bits property", " - drm/amd/pm: remove trailing semicolon from AMDGPU_PM_POLICY_ATTR macro", " - selftests/bpf: Use local type for flow_offload_tuple_rhash in", " xdp_flowtable", " - selftests/bpf: Use local type for bpf_fou_encap in test_tunnel_kern", " - Documentation: proc: fix section numbering in table of contents", " - arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Cobra", " - arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S", " - arm64: dts: qcom: ipq5424: Fix USB simple_bus_reg warnings", " - arm64: dts: qcom: sc8180x: Fix phy simple_bus_reg warning", " - 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: fix wrong pci_get_drvdata type in AER handlers", " - wifi: rtw88: fix wrong pci_get_drvdata type in AER handlers", " - wifi: rtw89: Correct data type for scan index to avoid infinite loop", " - wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA", " buffer", " - wifi: rtw89: add bounds check on firmware mac_id in link lookup", " - kconfig: fix potential NULL pointer dereference in conf_askvalue", " - soc: xilinx: Shutdown and free rx mailbox channel", " - pinctrl: mediatek: eint: Drop base from mtk_eint_chip_write_mask()", " - wifi: ath9k: fix OOB access from firmware tx status queue ID", " - ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint", " - Documentation/rv: Replace stale website link", " - 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", " - memory: tegra: Wire up system sleep PM ops", " - crypto: qat - fix heartbeat error injection", " - lib/vsprintf: Fix to check field_width and precision", " - dts: spacemit: set console baud rate on bpif3", " - pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path", " - dt-bindings: vendor-prefixes: Add Displaytech Ltd.", " - drm/gpuvm: take refcount on DRM device", " - drm/panel: Clean up S6E3HA2 config dependencies and fill help text", " - ARM: dts: rockchip: Add #{address,size}-cells to Chromium-based", " /firmware", " - arm64: dts: rockchip: Add #{address,size}-cells to Chromium-based", " /firmware", " - arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc", " - arm64: dts: imx8x-colibri: Correct SODIMM PAD settings", " - Revert \"arm64: dts: imx8mm-kontron: Add support for reading SD_VSEL", " signal\"", " - Revert \"arm64: dts: imx8mp-kontron: Add support for reading SD_VSEL", " signal\"", " - drm: renesas: rz-du: mipi_dsi: Fix return path on error", " - alarmtimer: Remove stale return description from alarm_handle_timer()", " - OPP: Fix race between OPP addition and lookup", " - crypto: ccp - Reverse the cleanup order in psp_dev_destroy()", " - crypto: ccp - Fix snp_filter_reserved_mem_regions() off-by-one", " - 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", " - ARM: multi_v7_defconfig: Correct QCOM_RPMH and QCOM_RPMHPD", " - nilfs2: fix backing_dev_info reference leak", " - media: qcom: camss: vfe: fix PIX subdev naming on VFE lite", " - media: iris: scale MMCX power domain on SM8250", " - media: venus: scale MMCX power domain on SM8250", " - iommu/amd: Fix a stale comment about which legacy mode is user visible", " - soc: mediatek: mtk-mmsys: Restore MT8167 routing masks lost during merge", " - bpf: fix crash in bpf_[set|remove]_dentry_xattr for negative dentries", " - uaccess: fix ignored_trailing logic in copy_struct_to_user()", " - arm64: dts: mediatek: mt8192-asurada: Move PCIe DMA bounce buffer to", " host", " - rust: alloc: fix `Vec::extend_with` SAFETY comment", " - clk: scmi: Fix clock rate rounding", " - arm64: dts: qcom: kodiak: Fix ICE reg size", " - arm64: dts: qcom: sm8450: Fix ICE reg size", " - drm/hisilicon/hibmc: add updating link cap in DP detect()", " - drm/hisilicon/hibmc: fix no showing when no connectors connected", " - drm/hisilicon/hibmc: move display contrl config to hibmc_probe()", " - 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()", " - scsi: hisi_sas: Add slave_destroy interface for v3 hw", " - 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)", " - IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier", " - RDMA/hns: Fix arithmetic overflow in calc_hem_config()", " - RDMA/mlx5: Fix UMR XLT cleanup on ODP populate failure", " - RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference", " - RDMA/hns: Initialize seqfile before creating file", " - drm/syncobj: Fix memory leak in drm_syncobj_find_fence()", " - selftests/bpf: Reject unsupported -k option in vmtest.sh", " - selftests/bpf: Fix test for refinement of single-value tnum", " - iommu/arm-smmu-qcom: Fix fastrpc compatible string in ACTLR client match", " table", " - selftests/mm: Fix resv_sz when parsing arm64 signal frame", " - firmware: arm_ffa: Honor partition info descriptor size", " - arm64: dts: imx8dxl-evk: Remove unnecessary PCIe EP properties", " - arm64: dts: imx8qxp-mek: Remove unnecessary PCIe EP vpcie-supply", " - arm64: dts: imx95-19x19-evk: Fix PCIe EP vpcie-supply", " - media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()", " - media: atomisp: gc2235: fix UAF and memory leak", " - staging: media: atomisp: fix loop shadowing in ia_css_stream_destroy()", " - riscv: dts: spacemit: set console baud rate on Milk-V Jupiter", " - firmware: smccc: Fix Arm SMCCC SOC_ID name call", " - firmware: arm_scmi: Read sensor config as 32-bit value", " - sysfs: clamp show() return value in sysfs_kf_read()", " - bitops: use common function parameter names", " - regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions", " - tools/nolibc: getopt: Fix potential out of bounds access", " - nilfs2: Fix return in nilfs_mkdir", " - net/sched: sch_drr: annotate data-races around cl->deficit", " - media: rockchip: rga: fix too small buffer size", " - firmware: arm_scmi: Fix OOB in scmi_power_name_get()", " - arm64: dts: qcom: lemans: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: monaco: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sc7180: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: kodiak: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8550: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8750: Add power-domain and iface clk for ice node", " - tracing: Bound synthetic-field strings with seq_buf", " - arm64: dts: qcom: lemans: Add eDP ref clock for eDP PHYs", " - writeback: drop now-unnecessary rcu_barrier() in", " cgroup_writeback_umount()", " - kernfs: fix suspicious RCU usage in kernfs_put()", " - 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", " - Revert \"treewide: Fix probing of devices in DT overlays\"", " - of: dynamic: Fix overlayed devices not probing because of fw_devlink", " - crypto: eip93 - fix reset ring register definition", " - cpufreq: Documentation: fix sampling_down_factor range", " - cpufreq: conservative: Simplify frequency limit handling", " - pwm: imx27: Fix variable truncation in .apply()", " - RDMA/mana_ib: Use ib_get_eth_speed for reporting port speed", " - bus: sunxi-rsb: Always check register address validity", " - pinctrl: spacemit: fix NULL check in spacemit_pin_set_config", " - 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/hns: Fix log flood after cmd_mbox failure", " - RDMA/counter: Fix incorrect port index in rdma_counter_init() error", " cleanup", " - pinctrl: meson: amlogic-a4: fix gpio output glitch", " - PM: sleep: Use complete() in device_pm_sleep_init()", " - 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", " - driver core: Fix missing jiffies conversion in", " deferred_probe_extend_timeout()", " - driver core: Guard deferred probe timeout extension with", " delayed_work_pending()", " - mtd: spi-nor: debugfs: Fix the flags list", " - mtd: spi-nor: Drop duplicate Kconfig dependency", " - ALSA: xen-front: Reset event channel state on stream clear", " - ALSA: xen-front: Connect event channel after stream prepare", " - ALSA: seq: oss: Fix UAF at handling events with embedded SysEx data", " - ALSA: seq: midi: Serialize output teardown with event_input", " - selftests: Fix Makefile target for nsfs", " - pinctrl: nuvoton: ma35d1: fix MFP register offset and pin table", " - pinctrl: cs42l43: Fix leaked pm reference on error path", " - pinctrl: cs42l43: Fix polarity on debounce", " - init/initramfs_test: wait_for_initramfs() before running", " - nvmet-tcp: fix page fragment cache leak in error path", " - nvmet-tcp: check return value of nvmet_tcp_set_queue_sock", " - nvme-pci: fix out-of-bounds access in nvme_setup_descriptor_pools", " - 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", " - iommu/amd: Fix premature break in init_iommu_one()", " - rtla/actions: Restore continue flag in actions_perform()", " - 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", " - bpftool: Fix typo in struct_ops map FD generation for light skeleton", " - libbpf: Fix UAF in strset__add_str()", " - ARM: tegra: Add #{address,size}-cells to Chromium-based /firmware", " - arm64: tegra: Add #{address,size}-cells to Chromium-based /firmware", " - 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", " - crypto: inside-secure/eip93 - Add check for devm_request_threaded_irq", " - crypto: tegra - Fix dma_free_coherent size error", " - crypto: tegra - Return ENOMEM when input buffer allocation fails for ccm", " - sched/deadline: Reject debugfs dl_server writes for offline CPUs", " - drm/msm/dp: fix HPD state status bit shift value", " - drm/msm/dp: Fix the ISR_* enum values", " - EDAC/igen6: Fix call trace due to missing release()", " - EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in", " skx_get_dimm_info", " - arm64: dts: st: Fix SAI addresses on stm32mp251", " - RDMA/umem: Add ib_umem_is_contiguous() stub for", " !CONFIG_INFINIBAND_USER_MEM", " - RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe", " - RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path", " - Revert \"media: venus: hfi_platform: Correct supported codecs for sc7280\"", " - 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", " - amba: use generic driver_override infrastructure", " - cdx: use generic driver_override infrastructure", " - Drivers: hv: vmbus: use generic driver_override infrastructure", " - rpmsg: use generic driver_override infrastructure", " - raid1: fix nr_pending leak in REQ_ATOMIC bad-block error path", " - bpf: fix BPF_PROG_QUERY OOB write and cgroup backward compat", " - selftests/bpf: add verification for BPF_PROG_QUERY attr size boundaries", " - libbpf: Skip hash computation when loader generation failed", " - libbpf: Skip endianness swap when loader generation failed", " - ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data", " writeback", " - spi: atmel: fix DMA channel and bounce buffer leaks", " - ASoC: rsnd: Fix RSND_SOC_MASK width to single nibble", " - NFSD: Fix delegation reference leak in nfsd4_revoke_states", " - ARM: imx3: Fix CCM node reference leak", " - HID: wiimote: Fix table layout and whitespace errors", " - wifi: ath12k: fix incorrect HT/VHT/HE/EHT MCS reporting in monitor mode", " - wifi: ath12k: fix NULL deref in change_sta_links for unready link", " - ata: libata: Fix ata_exec_internal()", " - ARM: imx31: Fix IIM mapping leak in revision check", " - x86/cpu: Keep the PROCESSOR_SELECT menu together", " - nvdimm/btt: Handle preemption in BTT lane acquisition", " - scsi: Revert \"scsi: Fix sas_user_scan() to handle wildcard and multi-", " channel scans\"", " - bpf: Reject exclusive maps as inner maps in map-in-map", " - libbpf: Reject non-exclusive metadata maps in the signed loader", " - libbpf: Skip initial_value override on signed loaders", " - libbpf: Skip max_entries override on signed loaders", " - 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", " - driver core: Use system_percpu_wq instead of system_wq", " - bpf: Reject exclusive maps for bpf_map_elem iterators", " - tick/sched: Fix TOCTOU in nohz idle time fetch", " - lib/test_meminit: use && for bools", " - riscv: dts: sophgo: sg2044: use hex for CPU unit address", " - riscv: dts: sophgo: sg2042: use hex for CPU unit address", " - configfs_lookup(): don't leave ->s_dentry dangling on failure", " - lockdep/selftests: Restore migrate_disable() state on PREEMPT_RT", " - lockdep/selftests: Restore sched_rt_mutex state on PREEMPT_RT", " - ext4: fix fast commit wait/wake bit mapping on 64-bit", " - drm/amdgpu: set sub_block_index for mca ras sub-blocks", " - bpftool: Use libbpf error code for flow dissector query", " - vhost: fix vhost_get_avail_idx for a non empty ring", " - iommu/vt-d: Fix RB-tree corruption in probe error path", " - perf/x86/amd/core: Always use the NMI latency mitigation", " - perf/x86/intel/uncore: Fix discovery unit lookup for multi-die systems", " - perf/x86/amd/uncore: Use Node ID to identify DF and UMC domains", " - xfrm: fix NAT-related field inheritance in SA migration", " - cxl/fwctl: Fix __fortify_panic", " - drm/amdkfd: always resume_all after suspend_all", " - of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array()", " fails", " - ocfs2: rebase copied fsdlm LVB pointers in locking_state", " - lib: kunit_iov_iter: repeatedly call alloc_pages_bulk()", " - 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: 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", " - netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock", " - ALSA: usb-audio: qcom: Initialize offload control return value", " - x86/cpu: Remove obsolete aperfmperf_get_khz() declaration", " - netfilter: conntrack: revert ct extension genid infrastructure", " - netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper", " is pptp", " - RDMA/hfi1: Open-code rvt_set_ibdev_name()", " - IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()", " - ALSA: hda: fix Kconfig dependency of HD Audio PCI", " - RDMA/irdma: Fix OOB read during CQ MR registration", " - RDMA/irdma: Initialize iwmr->access during MR registration", " - arm64: dts: imx8mp-kontron: Reduce EERAM SPI clock frequency", " - arm64: dts: imx95: Correct PCIe outbound address space configuration", " - arm64: dts: lx2162a-clearfog: use rev2 SoC dtsi", " - arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio codec as", " well", " - arm64: dts: imx8mp-kontron: Fix GPIO for display power switch", " - bpf: Clear rb node linkage when freeing bpf_rb_root", " - bpf: Check tail zero of bpf_map_info", " - 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: cpu_ops: Change return value type of cpu_is_stopped() to bool", " - riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe", " - ALSA: seq: Clear variable event pointer on read", " - bpf: Fix NMI/tracepoint re-entry deadlock on lru locks", " - kunit:tool: Don't write to stdout when it should be disabled", " - powerpc/8xx: implement get_direction() in cpm1", " - bpf: Fix NULL pointer dereference in bpf_task_from_vpid()", " - ACPI: IPMI: Fix message kref handling on dead device", " - cpufreq: Documentation: fix conservative governor freq_step description", " - thermal: testing: reject missing command arguments", " - btrfs: don't force DIO writes to be serialized", " - IB/mlx5: Don't take the rereg_mr fallback without a new translation", " - IB/mlx5: Properly support implicit ODP rereg_mr", " - IB/mlx5: Remove unused mkc bits in mlx5r_umr_update_mr_page_shift()", " - IB/mlx5: Pull the pdn out of the depths of the umr machinery", " - IB/mlx5: Don't mangle the mr->pd inside the rereg callback", " - spi: ep93xx: fix double-free of zeropage on DMA setup failure", " - ASoC: amd: acp-sdw-legacy: Bound DAI link iteration", " - ASoC: amd: acp-sdw-sof: Bound DAI link iteration", " - firmware_loader: Fix recursive lock in device_cache_fw_images()", " - configfs: fix lockless traversals of ->s_children", " - watchdog: unregister PM notifier on watchdog unregister", " - pinctrl: qcom: Fix resolving register base address from device node", " - 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", " - ARM: configs: Drop duplicated CONFIG_EXT4_FS", " - wifi: mt76: mt7925: clean up DMA on probe failure", " - wifi: mt76: use kfree_rcu for offchannel link in mt76_put_vif_phy_link", " - wifi: mt76: mt7996: add missing max_remain_on_channel_duration", " - wifi: mt76: mt7925: fix stale pointer comparisons in change_vif_links", " - wifi: mt76: mt7925: keep TX BA state in the primary WCID", " - wifi: mt76: mt792x: skip MLD header rewrite for 802.3 encap TX", " - wifi: mt76: mt7925: validate skb length in testmode query", " - wifi: mt76: mt7996: Fix possible token leak in mt7996_tx_prepare_skb()", " - wifi: mt76: mt7996: Fix possible NULL pointer dereference in", " mt7996_mac_write_txwi_80211()", " - wifi: mt76: mt7996: fix reading zeroed info->control.flags after", " mt76_tx_status_skb_add()", " - wifi: mt76: mt7996: limit work in set_bitrate_mask", " - 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", " - wifi: mt76: mt7925: fix potential tx_retries underflow", " - wifi: mt76: mt7996: fix potential tx_retries underflow", " - btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()", " - ALSA: aloop: Drop superfluous break", " - gpio: mt7621: fix interrupt banks mapping on gpio chips", " - wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is", " reported", " - fbdev: sm501fb: Fix buffer errors in OF binding code", " - vfs: add FS_USERNS_DELEGATABLE flag and set it for NFS", " - hwmon: (it87) Clamp negative values to zero in set_fan()", " - btrfs: zoned: don't account data relocation space-info in statfs free", " space", " - Revert \"btrfs: fix the file offset calculation inside", " btrfs_decompress_buf2page()\"", " - btrfs: zoned: always set max_active_zones for zoned devices", " - btrfs: annotate lockless read of defrag_bytes in should_nocow()", " - btrfs: fix deadlock cloning inline extent when using flushoncommit", " - igc: skip RX timestamp header for frame preemption verification", " - ASoC: sma1307: Fix uevent string leaks in fault worker", " - IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified", " - NFSD: Handle layout stid in nfsd4_drop_revoked_stid()", " - 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", " - virtio: rtc: tear down old virtqueues before restore", " - virtio_console: read size from config space during device init", " - vduse: Requeue failed read to send_list head", " - tools/virtio: check mmap return value in vringh_test", " - vdpa/octeon_ep: Fix PF->VF mailbox data address calculation", " - vdpa/octeon_ep: fix IRQ-to-ring mapping in interrupt handler", " - ASoC: cs35l56: Fix missing calls to wm_adsp2_remove()", " - ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend fails", " - ext4: fix ERR_PTR(0) in ext4_mkdir()", " - tools: missed broadcast_neigh if_link uapi header", " - netlink: specs: rt-link: missed broadcast-neigh", " - bonding: 3ad: add lacp_strict configuration knob", " - bonding: 3ad: fix carrier when no usable slaves", " - 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()", " - vfio/qat: fix f_pos race in qat_vf_resume_write()", " - bpf: Tighten cgroup storage cookie checks for prog arrays", " - pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag", " - pinctrl: airoha: an7581: add missed gpio32 pin group", " - pinctrl: airoha: an7581: fix misprint in gpio19 pinconf", " - arm64: dts: allwinner: a523: Add missing GPIO interrupt", " - ASoC: cs35l56: Fix possible uninitialized value in", " cs35l56_spi_system_reset()", " - s390/process: Fix kernel thread function pointer type", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for", " non-serdev device", " - Bluetooth: eir: Fix stack OOB write when prepending the Flags AD", " - Bluetooth: hci_event: fix simultaneous discovery stuck in FINDING", " - Bluetooth: hci_core: Fix UAF in hci_unregister_dev()", " - Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path", " - Bluetooth: hci: validate codec capability element length", " - Bluetooth: vhci: validate devcoredump state before side effects", " - fs: efs: remove unneeded debug prints", " - RDMA/mlx5: Remove DCT restrack tracking", " - 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: SOF: Intel: hda-sdw-bpt: select SND_SOF_SOF_HDA_SDW_BPT properly", " - 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: dsa: qca8k: fix led devicename when using external mdio bus", " - 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", " - net: pfcp: allocate per-cpu tstats for PFCP netdevs", " - 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: Unregister cxl_acpi in cxl_test_init() error path", " - 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", " - ALSA: usb-audio: qcom: Guard sideband endpoint removal", " - ALSA: seq: Fix kernel heap address leak in bounce_error_event()", " - spi: xilinx: use FIFO occupancy register to determine buffer size", " - iommu: Avoid copying the user array twice in the full-array copy helper", " - 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", " - virtio_net: do not allow tunnel csum offload for non GSO packets", " - net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net/sched: sch_dualpi2: 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", " - net: watchdog: fix refcount tracking races", " - net: ethernet: mtk_wed: fix loading WO firmware for MT7986", " - net/sched: sch_dualpi2: Add missing module alias", " - bpf: Run generic devmap egress prog on private skb", " - net/mlx5: Check max_macs devlink param value against max capability", " - bpf: Fix setting retval to -EPERM for cgroup hooks not returning errno", " - octeontx2-af: npc: Fix size of entry2cntr_map", " - net: ethernet: mtk_wed: debugfs: correct index in wed_amsdu_show()", " - net: wwan: t7xx: check skb_clone in control TX", " - 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", " - net: bcmgenet: Use weighted round-robin TX DMA arbitration", " - net: airoha: Fix register index for Tx-fwd counter configuration", " - net: airoha: Fix debugfs new-tuple display for IPv4 ROUTE entries", " - kcm: use WRITE_ONCE() when changing lower socket callbacks", " - ALSA: seq: oss: Serialize readq reset state with q->lock", " - ALSA: seq: avoid stale FIFO cells during resize", " - 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: Fix typo in verify_umulti_link_info", " - selftests/bpf: Initialize operation name before use", " - bpf: Fix bpf_get/setsockopt to tos for ipv4-mapped ipv6 socket", " - udf: fix nls leak on udf_fill_super() failure", " - bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()", " - net: remove addr_len argument of recvmsg() handlers", " - sockmap: Fix use-after-free in udp_bpf_recvmsg()", " - 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", " - tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)", " - net: airoha: Fix always-true condition in PPE1 queue reservation loop", " - net: ethernet: oa_tc6: Remove FCS size in RX frame", " - ionic: Fix check in ionic_get_link_ext_stats", " - RDMA/bnxt_re: Free SRQ toggle page after firmware teardown", " - RDMA/bnxt_re: Avoid displaying the kernel pointer", " - RDMA/bnxt_re: Fail DBR related page allocation UAPIs if the feature is", " disabled", " - ksmbd: fix use-after-free in same_client_has_lease()", " - mfd: rsmu: Fix page register setup", " - mfd: cs42l43: Sanity check firmware size", " - ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write", " - 9p: avoid returning ERR_PTR(0) from mkdir operations", " - eventpoll: rename ep_remove_safe() back to ep_remove()", " - eventpoll: expand top-of-file overview / locking doc", " - eventpoll: rename attach_epitem() to ep_attach_file()", " - 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", " - i3c: master: svc: Fix missed IBI after false SLVSTART on NPCM845", " - staging: nvec: fix use-after-free in nvec_rx_completed()", " - perf debuginfo: Fix libdw API contract violations", " - coresight: cti: Fix DT filter signals silently ignored", " - soundwire: don't program SDW_SCP_BUSCLOCK_SCALE on a unattached", " Peripheral", " - soundwire: fix bug in sdw_add_element_group_count found by syzkaller", " - coresight: ete: Always save state on power down", " - 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", " - perf sched: Add missing mmap2 handler in timehist", " - PCI: loongson: Do not ignore downstream devices on external bridges", " - rust: alloc: fix assert in `Vec::reserve` doc test", " - bus: mhi: ep: Fix potential deadlock in mhi_ep_reset_worker()", " - coresight: fix missing error code when trace ID is invalid", " - clk: qcom: cmnpll: Account for reference clock divider", " - phy: phy-can-transceiver: Check driver match and driver data against", " NULL", " - perf pmu: Skip test on Arm64 when #slots is zero", " - clk: at91: sam9x7: Fix gmac_gclk clock definition", " - soundwire: intel_ace2x: release bpt_stream when close it", " - coresight: Fix source not disabled on idr_alloc_u32 failure", " - mailbox: mpfs: fix check for syscon presence in mpfs_mbox_inbox_isr()", " - mailbox: mtk-adsp: fix UAF during device teardown", " - PCI: dwc: Fix signedness bug in fault injection test code", " - perf build-id: Fix off-by-one bug when printing kernel/module build-id", " - 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", " - perf test amd ibs: Fix incorrect kernel version check", " - gpib: Fix inappropriate ioctl error return", " - char: tlclk: fix use-after-free in tlclk_cleanup()", " - gpib: fix double decrement of descriptor_busy in command_ioctl()", " - clk: renesas: rzg2l: Rename iterator in for_each_mod_clock() to avoid", " shadowing", " - powerpc tools perf: Initialize error code in auxtrace_record_init", " function", " - PCI: qcom: Disable ASPM L0s for SA8775P", " - perf header: Sanity check HEADER_EVENT_DESC attr.size before swap", " - 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", " - drm/amd/display: Add missing kdoc for ALLM parameters", " - thunderbolt: debugfs: Fix margining error counter buffer leak", " - dmaengine: imx-sdma: Refine spba bus searching in probe", " - dt-bindings: dma: nvidia,tegra186-gpc-dma: Make reset optional", " - perf: Fix off-by-one stack buffer overflow in kallsyms__parse()", " - perf annotate: Fix crashes on empty annotate windows", " - perf tools: Guard test_bit from out-of-bounds sample CPU", " - perf sched: Fix thread reference leak in latency_switch_event", " - perf tools: Add bounds check to cpu__get_node()", " - perf sched: Cap max_cpu at MAX_CPUS in timehist sample processing", " - perf sched: Fix register_pid() overflow, strcpy, and BUG_ON", " - perf mmap: Guard cpu__get_node() return in aio_bind()", " - perf stat: Bounds-check CPU index in topology aggregation callbacks", " - perf c2c: Bounds-check CPU and node IDs before bitmap and array access", " - perf c2c: Bounds-check CPU IDs in setup_nodes() topology loop", " - perf sched: Clean up idle_threads entry on init failure", " - perf sched: Use thread__put() in free_idle_threads()", " - perf sched: Replace BUG_ON and add NULL checks in replay event helpers", " - perf mmap: Fix NULL deref in aio cleanup on alloc failure", " - perf stat: Introduce perf_env__get_cpu_topology() to guard NULL env->cpu", " - perf c2c: Fix use-after-free in he__get_c2c_hists() error path", " - perf timechart: Fix cpu2y() OOB read on untrusted CPU index", " - perf tools: Fix int16_t truncation of max_cpu_num in set_max_cpu_num()", " - dt-bindings: clock: qcom: Add X1P42100 camera clock controller", " - clk: qcom: camcc-x1e80100: Add support for camera QDSS debug clocks", " - mshv: add bounds check on vp_index in mshv_intercept_isr()", " - dmaengine: qcom: gpi: set DMA_PRIVATE capability", " - dmaengine: Fix possible use after free", " - dmaengine: dma-axi-dmac: Properly free struct axi_dmac_desc", " - dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor", " - clk: qcom: a53: Corrected frequency multiplier for 1152MHz", " - sunrpc: Fix error handling in rpc_sysfs_xprt_switch_add_xprt_store()", " - pNFS/filelayout: fix cheking if a layout is striped", " - 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", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in", " pg_get_mirror_count_write", " - PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro", " - pwm: rzg2l-gpt: Add missing newlines to dev_err_probe() messages", " - PCI: meson: Propagate devm_add_action_or_reset() failure", " - PCI: meson: Add missing remove callback", " - fs/ntfs3: resize log->one_page_buf when adopting on-disk page size", " - platform/x86/intel/vsec: Decouple add/link helpers from PCI", " - platform/x86/intel/vsec: Switch exported helpers from pci_dev to device", " - platform/x86/intel/vsec: Return real error codes from registration path", " - platform/x86/intel/vsec: Restore BAR fallback for header walk", " - perf tools: Fix get_max_num() size_t underflow on empty sysfs file", " - perf tools: Use scnprintf() in cpu_map__snprint() to prevent overflow", " - perf tools: Use perf_env__get_cpu_topology() in machine__resolve()", " - PCI: rcar-host: Remove unused LIST_HEAD(res)", " - perf sched: Bounds-check prio before test_bit() in timehist", " - perf sched: Fix idle-hist callchain display using wrong rb_first variant", " - perf bpf: Use scnprintf() in snprintf_hex() and", " synthesize_bpf_prog_name()", " - perf hists: Fix snprintf() in hists__scnprintf_title() UID filter path", " - xprtrdma: Fix ep kref imbalance on ADDR_CHANGE", " - xprtrdma: Initialize re_id before removal registration", " - xprtrdma: Check frwr_wp_create() during connect", " - xprtrdma: Document and assert reply-handler invariants", " - xprtrdma: Resize reply buffers before reposting receives", " - xprtrdma: Sanitize the reply credit grant after parsing", " - xprtrdma: Repost Receive buffers for malformed replies", " - xprtrdma: Return sendctx slot after Send preparation failure", " - perf s390: Fix TEXTREL in Python extension by compiling as PIC", " - perf cs-etm: Queue context packets for frontend", " - perf pmu: Fix pmu_id() heap underwrite on empty identifier file", " - perf pmu: Fix perf_pmu__parse_scale/unit() OOB access on empty sysfs", " file", " - tools lib api: Fix missing null termination in filename__read_int/ull()", " - perf symbols: Fix signed overflow in sysfs__read_build_id() size check", " - perf symbols: Bounds-check .gnu_debuglink section data", " - perf intel-pt: Fix snprintf size tracking bug in insn decoder", " - perf tools: Fix thread__set_comm_from_proc() on empty comm file", " - perf hwmon: Fix off-by-one null termination on sysfs reads", " - perf hwmon: Use scnprintf() in hwmon_pmu__for_each_event()", " - perf hwmon: Fix parse_hwmon_filename() strlcpy buffer overflow", " - perf symbols: Bounds-check descsz in sysfs__read_build_id() GNU fallback", " - perf hwmon: Guard label read against empty or failed reads", " - perf tools: Use snprintf() in dso__read_running_kernel_build_id()", " - tools lib api: Fix filename__write_int() writing uninitialized stack", " data", " - tools lib api: Fix mount_overload() snprintf truncation and toupper", " range", " - perf bpf: Add NULL check for btf__type_by_id() in", " synthesize_bpf_prog_name()", " - perf bpf: Fix map data leak in bpf_metadata_create() on alloc failure", " - perf bpf: Fix metadata leak in perf_env__add_bpf_info() on duplicate", " insert", " - perf symbols: Add bounds checks to elf_read_build_id() note iteration", " - perf symbols: Add bounds checks to read_build_id() note iteration in", " minimal build", " - dt-bindings: phy: sc8280xp-qmp-pcie: Disallow bifurcation register on", " Purwa", " - PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()", " - PCI: mediatek: Use actual physical address instead of virt_to_phys()", " - phy: freescale: phy-fsl-imx8qm-lvds-phy: Fix missing", " pm_runtime_disable() on probe error path", " - PCI: dwc: Avoid dwc_pcie_rasdes_debugfs_deinit() NULL dereference when", " no RAS DES capability", " - Revert \"PCI/MSI: Unmap MSI-X region on error\"", " - apparmor: fix shadowing of plabel that prevents cache from being updated", " - apparmor: fix race in unix socket mediation when peer_path is used", " - apparmor: fix refcount leak when updating the sk_ctx", " - security/apparmor/apparmorfs.c: conditionally compile", " get_loaddata_common_ref()", " - apparmor: check label build before no_new_privs test", " - apparmor: aa_label_alloc use aa_label_free on alloc failure", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [41/57]: apparmor-next 7.1:", " apparmor: fix rawdata_f_data implicit flex array\"", " - apparmor: fix rawdata_f_data implicit flex array", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [38/57]: apparmor-next 7.1:", " apparmor: grab ns lock and refresh when looking up changehat child", " profiles\"", " - apparmor: grab ns lock and refresh when looking up changehat child", " profiles", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [44/57]: apparmor-next 7.1:", " apparmor: fix potential UAF in aa_replace_profiles\"", " - apparmor: fix potential UAF in aa_replace_profiles", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor: fix NULL pointer dereference in", " unpack_pdb\"", " - apparmor: fix NULL pointer dereference in unpack_pdb", " - apparmor: remove or add symlinks to rawdata according to export_binary", " - apparmor: Fix return in ns_mkdir_op", " - apparmor: fail policy unpack on accept2 allocation failure", " - apparmor: aa_getprocattr free procattr leak on format failure", " - apparmor: put secmark label after secid lookup", " - apparmor: don't audit files pointing to aa_null.dentry", " - apparmor: fix uninitialised pointer passed to", " audit_log_untrustedstring()", " - i3c: mipi-i3c-hci: Preserve RUN bit when aborting DMA ring", " - i3c: master: Make hot-join workqueue freezable to block hot-join during", " suspend", " - i3c: master: Move rstdaa error suppression", " - i3c: master: Consolidate Hot-Join DAA work in the core", " - i3c: master: Ensure Hot-Join operations are stopped on shutdown", " - i3c: master: Defer new-device registration out of DAA caller context", " - i3c: master: Prevent reuse of dynamic address on device add failure", " - apparmor: fix label can not be immediately before a declaration", " - accel/ivpu: fix HWS command queue leak on registration failure", " - sparc: led: avoid trimming a newline from empty writes", " - perf symbols: Fix bswap copy-paste error for 32-bit ELF p_filesz", " - perf symbols: Validate p_filesz before use in filename__read_build_id()", " - perf symbols: Break infinite loop on zero-filled notes in", " sysfs__read_build_id()", " - perf tools: Add O_CLOEXEC to open() calls in DSO and ELF code", " - perf tools: Fix uninitialized pathname on uncompressed fallback in", " filename__decompress()", " - perf dso: Fix heap overflow in dso__get_filename() on decompressed path", " - perf dso: Set error code when open() fails on uncompressed fallback path", " - perf tools: Use snprintf() for root_dir path construction", " - perf hwmon: Fix fd check to accept fd 0 in hwmon_pmu__describe_items()", " - perf sched: Replace (void*)1 sentinel with proper runtime allocation", " - perf bpf: Validate func_info_rec_size and sub_id in", " synthesize_bpf_prog_name()", " - perf bpf: Reject oversized BPF metadata events that truncate header.size", " - perf bpf: Bounds-check array offsets in bpil_offs_to_addr()", " - perf cs-etm: Reject CPU IDs that would overflow signed comparison", " - gpio: mlxbf3: fail probe if gpiochip registration fails", " - drm/i915: clear CRTC color blob pointers after dropping refs", " - drm/xe: Fix wa_oob codegen recipe for external module builds", " - spi: dw: fix wrong BAUDR setting after resume", " - i3c: master: Update dev_nack_retry_count under maintenance lock", " - i3c: master: Add missing runtime PM get in dev_nack_retry_count_store()", " - ALSA: usb-audio: qcom: Free sideband sg_table objects", " - xfrm: annotate data-races around xfrm_policy_count[] and", " xfrm_policy_default[]", " - xfrm: validate selector family and prefixlen during match", " - perf machine: Use snprintf() for guestmount path construction", " - perf cs-etm: Validate num_cpu before metadata allocation", " - perf cs-etm: Require full global header in auxtrace_info size check", " - perf cs-etm: Bounds-check CPU in cs_etm__get_queue()", " - perf bpf: Validate array presence before casting BPF prog info pointers", " - perf dso: Set standard errno on decompression failure", " - ASoC: tlv320aic3x: restrict CLKDIV bypass Q values in dual-rate mode", " - drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free", " - drm/amd/display: Fix mem_type change detection for async flips", " - drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm", " - drm/amdgpu: initialize irq.lock spinlock earlier", " - 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", " - ALSA: usb-audio: qcom: reject stream disable with no active interface", " - ALSA: usb-audio: qcom: clear opened when stream enable fails", " - 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()", " - dpaa2-switch: fix VLAN upper check not rejecting bridge join", " - devlink: Fix parent ref leak in devl_rate_node_create()", " - devlink: Fix parent ref leak on tc-bw failure", " - net: airoha: fix foe_check_time allocation size", " - net: macb: add TX stall timeout callback to recover from lost TSTART", " write", " - flow_dissector: check device type before reading ETH_ADDRS", " - selftests: vlan_bridge_binding: Fix flaky operational state check", " - 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: Restore initial state on failed device_rename() in", " cfg802154_switch_netns()", " - ieee802154: Avoid calling WARN_ON() on -ENOMEM in", " cfg802154_switch_netns()", " - ieee802154: Remove WARN_ON() in cfg802154_pernet_exit()", " - ieee802154: fix kernel-infoleak in dgram_recvmsg()", " - mac802154: Prevent overwrite return code in", " mac802154_perform_association()", " - md/raid1: honor REQ_NOWAIT when waiting for behind writes", " - md/raid1: free r1_bio when REQ_NOWAIT is set and read would block on", " retry", " - netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()", " - netfilter: ipset: make sure gc is properly stopped", " - netfilter: nft_payload: reject offsets exceeding 65535 bytes", " - netfilter: nft_meta_bridge: add validate callback for get operations", " - netfilter: nft_flow_offload: zero device address for non-ether case", " - netfilter: nf_reject: skip iphdr options when looking for icmp header", " - netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak", " - mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()", " - irqchip/crossbar: Fix parent domain resource leak", " - alloc_tag: fix use-after-free in /proc/allocinfo after module unload", " - selftests/mm: restore default nr_hugepages value via exit trap in", " charge_reserved_hugetlb.sh", " - selftests/mm: restore default nr_hugepages value via exit trap in", " hugetlb_reparenting_test.sh", " - selftests/mm: fix hugetlb pathname construction in", " hugetlb_reparenting_test.sh", " - selftests/mm: fix cgroup task placement and drop memory.current checks", " in hugetlb_reparenting_test.sh", " - selftests/mm: size tmpfs according to PMD page size in", " split_huge_page_test", " - selftests/mm: free dynamically allocated PMD-sized buffers in", " split_huge_page_test", " - selftest/mm: register existing mapping with userfaultfd in hugetlb-", " mremap", " - selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap", " - selftests/mm: skip uffd-stress test when nr_pages_per_cpu is zero", " - 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", " - net: emac: Fix NULL pointer dereference in emac_probe", " - net/sched: act_ct: fix nf_connlabels leak on two error paths", " - net: airoha: Fix skb->priority underflow in airoha_dev_select_queue()", " - ipv6: ndisc: fix NULL deref in accept_untracked_na()", " - dpaa2-switch: do not accept VLAN uppers while bridged", " - 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", " - bpftool: Fix vmlinux BTF leak in cgroup commands", " - bpf: zero-initialize the fib lookup flow struct", " - bpf: Fix effective prog array index with BPF_F_PREORDER", " - power: sequencing: fix ABBA deadlock in pwrseq_device_unregister()", " - gpiolib: initialize return value in gpiochip_set_multiple()", " - 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()", " - ice: call netif_keep_dst() once when entering switchdev mode", " - rtc: isl1208: Balance enable_irq_wake() with disable_irq_wake() on", " cleanup", " - 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", " - i40e: Fix i40e_debug() to use struct i40e_hw argument", " - rtc: msc313: fix NULL deref in shared IRQ handler at probe", " - ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().", " - eth: bnxt: rename ring_err_stats -> ring_drv_stats", " - eth: bnxt: improve the timing of stats", " - ipv4: fib: Don't ignore error route in local/main tables.", " - md/raid5: use stripe state snapshot in break_stripe_batch_list()", " - md/raid5: avoid R5_Overlap races while breaking stripe batches", " - 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", " - gpio: davinci: fix IRQ domain leak on devm_kzalloc failure", " - 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: do not acquire dev->tx_global_lock in netdev_watchdog_up()", " - net: dsa: sja1105: round up PTP perout pin duration", " - veth: fix NAPI leak in XDP enable error path", " - net: usb: lan78xx: restore VLAN and hash filters after link up", " - 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", " - ipv6: fix state corruption during proxy_ndp sysctl restart", " - ipv6: fix missing notification for ignore_routes_with_linkdown", " - eth: fbnic: fix ordering of heartbeat vs ownership", " - thermal: testing: zone: Flush work items during cleanup", " - ACPI: processor_idle: Mark LPI enter functions as __cpuidle", " - 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: dsa: realtek: fix memory leak in rtl8366rb_setup_led()", " - net: phy: realtek: Clear MDIO_AN_10GBT_CTRL_ADV10G bit", " - octeontx2-af: Validate NIX maximum LFs correctly", " - 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", " - LoongArch: Move struct kimage forward declaration before use", " - LoongArch: BPF: Fix outdated tail call comments", " - LoongArch: BPF: Fix off-by-one error in tail call", " - ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count", " - net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync", " - dt-bindings: net: renesas,ether: Drop example \"ethernet-phy-", " ieee802.3-c22\" fallback", " - selftests: tls: size splice_short pipe by page size", " - 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", " - ALSA: FCP: Fix NULL pointer dereference in interface lookup", " - tracing: probes: fix typo in a log message", " - spi: sh-msiof: abort transfers when reset times out", " - ACPI: RIMT: Only defer the IOMMU configuration in init stage", " - riscv: Fix 32-bit call_on_irq_stack() frame pointer ABI", " - gpio: mvebu: fail probe if gpiochip registration fails", " - gpio: htc-egpio: use managed gpiochip registration", " - net: pse-pd: scope pse_control regulator handle to kref lifetime", " - seg6: validate SRH length before reading fixed fields", " - qede: fix out-of-bounds check for cqe->len_list[]", " - sctp: fix SCTP_RESET_STREAMS stream list length limit", " - MIPS: DEC: Ensure RTC platform device deregistration upon failure", " - MIPS: mm: Add check for highmem before removing memory block", " - ASoC: codecs: lpass-va-macro: Fix LPASS Codec Version for SC7280", " - hwmon: adm1275: Prevent reading uninitialized stack", " - hwmon: (pmbus) Fix passing events to regulator core", " - hwmon: (aspeed-g6-pwm-tach) Guard fan RPM calculation against divide-by-", " zero", " - ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump", " - usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()", " - net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy", " - net: libwx: fix VMDQ mask for 1-queue mode", " - 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", " - drm/panthor: Fix potential invalid pointer deref in", " group_process_tiler_oom()", " - drm/panthor: Don't overrule pending immediate ticks in", " sched_resume_tick()", " - drm/panthor: Fix a leak when a group is evicted before the tiler OOM is", " serviced", " - drm/panthor: Interrupt group start/resumption if group_bind_locked()", " fails", " - tracing/eprobes: Allow use of BTF names to dereference pointers", " - tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg", " - tracing/events: Fix to check the simple_tsk_fn creation", " - tracing: eprobe: read the complete FILTER_PTR_STRING pointer", " - tracing/fprobe: Fix NULL pointer dereference in fprobe_fgraph_entry()", " - tracing/probes: Make the $ prefix mandatory for comm access", " - irqchip/gic-v3-its: Fix OF node reference leak", " - irqchip/ts4800: Fix missing chained handler cleanup on remove", " - sctp: fix addr_wq_timer race in sctp_free_addr_wq()", " - virtio_net: disable cb when NAPI is busy-polled", " - cxgb4: Fix decode strings dump for T6 adapters", " - selftests: drv-net: tso: don't touch dangerous feature bits", " - 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: dualpi2: clear stale classification on filter miss", " - 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: Fix double netfs initialisation in afs_root_iget()", " - afs: use kvfree() to free memory allocated by kvcalloc()", " - afs: Remove erroneous seq |= 1 in volume lookup loop", " - afs: Fix bulk lookup malfunction due to change in dir_emit() API", " - afs: Fix misplaced inc of net->cells_outstanding", " - afs: Fix reinitialisation of the inode, in particular ->lock_work", " - afs: Fix callback service message parsers to pass through -EAGAIN", " - afs: Fix missing NULL pointer check in afs_break_some_callbacks()", " - afs: Fix vllist leak", " - afs: Fix lack of locking around modifications of net->cells_dyn_ino", " - afs: Fix premature cell exposure through /afs", " - 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", " - ovl: fix comment about locking order", " - iomap: guard io_size EOF trim against concurrent truncate underflow", " - netfs: Fix writethrough to use collection offload", " - netfs: Fix writeback error handling", " - netfs: Fix folio state after ENOMEM whilst under writeback iteration", " - drm/xe/pt: Fix NULL pointer dereference in xe_pt_zap_ptes_entry()", " - drm/xe/userptr: Hold notifier_lock for write on inject test path", " - drm/xe/hw_engine: Fix double-free of managed BO in error path", " - drm/xe/pf: Don't attempt to process FAST_REQ or EVENT relays", " - x86/uprobes: Keep shadow stack in sync for emulated CALLs", " - uprobes/x86: Use proper mm_struct in __in_uprobe_trampoline", " - cifs: Fix missing credit release on failure in cifs_issue_read()", " - ata: sata_gemini: unwind clocks on IDE pinctrl errors", " - ata: libata-scsi: limit simulated SCSI command copy to response length", " - 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: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()", " - HID: bpf: Fix hid_bpf_get_data() range check", " - selftests/hid: Load only requested struct_ops maps", " - selftests/hid: Cover hid_bpf_get_data() size overflow", " - arm64/sysreg: Fix BWE field encoding in ID_AA64DFR2_EL1", " - net: usb: net1080: validate packet_len before pad-byte access in", " rx_fixup", " - netfilter: xt_u32: reject invalid shift counts", " - netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()", " - netfilter: nft_set_rbtree: get command skips end element with open", " interval", " - netfilter: xt_connmark: reject invalid shift parameters", " - net/mlx5: LAG, MPESW, Fix missing complete() on devcom error", " - net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation", " - net/mlx5e: Fix HV VHCA stats agent registration race", " - net/mlx5e: Fix publication race for priv->channel_stats[]", " - net: microchip: vcap: fix races on the shared Super VCAP block", " - net: qualcomm: rmnet: validate MAP frame length before ingress parsing", " - net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload", " - 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: sco: Fix a race condition in sco_sock_timeout()", " - Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length", " - Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()", " - Bluetooth: L2CAP: fix tx ident leak for commands without a response", " - ring-buffer: Fix event length with forced 8-byte alignment", " - accel/amdxdna: Use unsigned long for nr_pages in amdxdna_hmm_register()", " - net/tls: Consume empty data records in tls_sw_read_sock()", " - net: usb: lan78xx: disable VLAN filter in promiscuous mode", " - gpio: dwapb: reduce allocation to single kzalloc", " - gpio: dwapb: Defer clock gating until noirq", " - tracing: Make tracepoint_printk static as not exported", " - accel/amdxdna: Fix potential amdxdna_umap lifetime race", " - drm/v3d: Reject invalid indirect BO handle in indirect CSD setup", " - net: mdio: select REGMAP_MMIO instead of depending on it", " - net/sched: cake: reject overhead values that underflow length", " - octeontx2-pf: check DMAC extraction support before filtering", " - perf/x86/amd/core: Avoid enabling BRS from the SVM reload path", " - gpio: mvebu: free generic chips on unbind", " - ipv4: igmp: annotate data-races around im->users", " - ipv4: igmp: annotate data-races around timer-related fields", " - ipv4: igmp: Fix potential memory leaks in igmp_mod_timer() and", " igmp_stop_timer()", " - ipvs: pass parsed transport offset to state handlers", " - ipvs: use parsed transport offset in TCP state lookup", " - s390/zcrypt: Remove the empty file", " - SUNRPC: release lower rpc_clnt if killed waiting for XPRT_LOCKED", " - 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", " - drm/xe: remove duplicate include", " - smb: client: fix overflow in passthrough ioctl bounds check", " - idpf: add padding to PTP virtchnl structures", " - 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", " - octeontx2-pf: clear stale mailbox IRQ state before request_irq()", " - octeontx2-vf: clear stale mailbox IRQ state before request_irq()", " - arm64: fpsimd: Fix type mismatch in sve_{save,load}_state()", " - arm64: dts: s32g3: Fix SWT8 watchdog address", " - ARM: dts: imx6ul-var-som: fix warning for non-existent dc-supply", " property", " - arm64: dts: qcom: sdm630: describe adsp_mem region properly", " - arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Ringneck", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix ADC sampling times", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move divergent mecio1 ADC", " channels to board files", " - arm64: dts: ti: k3-am62a7-sk: Add bootph-all tag to vqmmc", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Enable internal ADC reference", " - arm64: dts: imx8ulp-evk: Correct Type-C int GPIO flags", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix GPIO names typo", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move gpio-line-names to board", " files", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix expander gpio line typo", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move expander gpio-line-names to", " board files", " - LoongArch: KVM: Validate irqchip index in irqfd routing", " - 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()", " - powerpc/pseries/Kconfig: Enable CONFIG_VPA_PMU to be used with KVM", " - KVM: s390: pci: Fix GISC refcount leak on AIF enable failure", " - KVM: s390: pci: Fix handling of AIF enable without AISB", " - KVM: SEV: Do not allow intra-host migration/mirroring of SNP VMs", " - KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs", " - KVM: x86: Nullify irqfd->producer if updating IRTE for bypass fails", " - KVM: nVMX: Put vmcs12 pages if nested VM-Enter fails due to invalid", " guest state", " - KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers", " - KVM: arm64: nv: Drop bogus WARN for write to ZCR_EL2", " - KVM: arm64: nv: Write ESR_EL2 for injected nested SError exceptions", " - KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()", " - 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: efifb: fix memory leak in efifb_probe()", " - 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: Check runtime resume during probe", " - ASoC: mediatek: mt8192: Release reserved memory on cleanup", " - ASoC: mediatek: mt8183: Check runtime resume during probe", " - 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: nft_set_pipapo: don't leak bad clone into future transaction", " - 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", " - selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()", " - selinux: fix incorrect execmem checks on overlayfs", " - 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/brs: Fix kernel address leakage", " - perf/x86/amd/lbr: Fix kernel address leakage", " - cpufreq: schedutil: Fix uncleared need_freq_update on the .adjust_perf()", " path", " - cpufreq: intel_pstate: Set non-turbo capacity to HWP_GUARANTEED_PERF()", " - 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: retrieve ethhdr after potential skb realloc on RX", " - 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: ensure minimal ethernet header on TX", " - 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: clean untagged VLAN on netdev registration failure", " - batman-adv: frag: fix primary_if leak on failed linearization", " - batman-adv: mcast: avoid OOB read of num_dests header", " - 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", " - lockd: Plug nlm_file leak when nlm_do_fopen() fails", " - lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure", " - 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()", " - mm/mm_init: fix pageblock migratetype for ZONE_DEVICE compound pages", " - power: supply: cpcap-battery: Fix missing nvmem_device_put() causing", " reference leak", " - power: supply: max17042: fix OF node reference imbalance", " - mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch", " - mm/memory_hotplug: fix incorrect altmap passing in error path", " - 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: bound NTFS_DE view.data_off in", " UpdateRecordData{Root,Allocation}", " - ntfs3: cap RESTART_TABLE free-chain walker at rt->used", " - ntfs3: fix out-of-bounds read in decompress_lznt", " - landlock: Fix LANDLOCK_SCOPE_SIGNAL bypass on the SIGIO path", " - power: supply: charger-manager: fix refcount leak in is_full_charged()", " - selftests/landlock: Test SCOPE_SIGNAL on the SIGIO/fowner pgid path", " - 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", " - 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()", " - proc: only bump parent nlink when registering directories", " - fs/proc: fix KPF_KSM reported for all anonymous pages", " - powerpc/dt_cpu_ftrs: Set CPU_FTR_P11_PVR for Power11 and later", " processors", " - mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE", " - kcov: use WRITE_ONCE() for selftest mode stores", " - mtd: slram: remove failed entries from the device list", " - 9p: skip nlink update in cacheless mode to fix WARN_ON", " - power: supply: bq257xx: Fix VSYSMIN clamping logic", " - scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()", " - scsi: sas: Skip opt_sectors when DMA reports no real optimization hint", " - openrisc: Add full instruction cache invalidate functions", " - 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: fix UBSAN array-index-out-of-bounds in ocfs2_sum_rightmost_rec", " - 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: host: pci_generic: Fix the physical function check", " - 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()", " - s390/pkey: Check length in PKEY_VERIFYPROTK ioctl", " - s390/pkey: Check length in pkey_pckmo handler implementation", " - mtd: spi-nor: swp: Improve locking user experience", " - mtd: spi-nor: spansion: use die erase for multi-die devices only", " - mtd: rawnand: Pause continuous reads at block boundaries", " - openrisc: Fix jump_label smp syncing", " - mtd: maps: vmu-flash: fix NULL pointer dereference in initialization", " - taskstats: retain dead thread stats in TGID queries", " - irqchip/crossbar: Use correct index in crossbar_domain_free()", " - tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()", " - tpm: tpm2-sessions: wait for async KPP completion in tpm_buf_append_salt", " - sunrpc: fix uninitialized xprt_create_args structure", " - dmaengine: tegra: Fix burst size calculation", " - dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and", " ABORT_INT_MASK", " - platform/x86: dell-laptop: fix missing cleanups in init error path", " - platform/x86: ISST: Restore SST-PP control to all domains", " - 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", " - platform/x86/amd/pmc: Don't log during intermediate wakeups", " - pkey: Move keytype check from pkey api to handler", " - 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", " - hwmon: (max6697) add missing 'select REGMAP_I2C' to Kconfig", " - i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)", " - i2c: imx: fix locked bus on SMBus block-read of 0 (IRQ)", " - i2c: mediatek: fix WRRD for SoCs without auto_restart option", " - i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()", " - i2c: spacemit: fix spurious IRQ handling returning IRQ_HANDLED", " - ice: fix ice_init_link() error return preventing probe", " - tcp: Decrement tcp_md5_needed static branch", " - ufs: core: tracing: Do not dereference pointers in TP_printk()", " - xen/gntdev: fix error handling in ioctl", " - xfrm: use compat translator only for u64 alignment mismatch", " - 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()", " - NFS: Charge unstable writes by request size, not folio size", " - nvme-apple: Prevent shared tags across queues on Apple A11", " - nvmet: fix refcount leak in nvmet_sq_create()", " - netdev-genl: report NAPI thread PID in the caller's pid namespace", " - can: esd_usb: kill anchored URBs before freeing netdevs", " - can: isotp: use unconditional synchronize_rcu() in isotp_release()", " - can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER", " - can: isotp: serialize TX state transitions under so->rx_lock", " - 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: Reset register bounds before narrowing retval range in", " check_mem_access()", " - bpf,fork: wipe ->bpf_storage before bailouts that access it", " - bpf: Add missing access_ok call to copy_user_syms", " - block: remove redundant GD_NEED_PART_SCAN in add_disk_final()", " - block: fix race in blk_time_get_ns() returning 0", " - block: fix IORING_URING_CMD_REISSUE flags check in blkdev_uring_cmd", " - 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-pcache: reject option groups without values", " - 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: fix leaking uninitialized kernel memory", " - dm-integrity: fix a bug if the bio is out of limits", " - dm-integrity: don't increment hash_offset twice", " - dm-verity: avoid double increment of &use_bh_wq_enabled", " - dm-verity: fix a possible NULL pointer dereference", " - dm-verity: increase sprintf buffer size", " - dm-verity: make error counter atomic", " - dma-fence: Make dma_fence_dedup_array() robust against 0-count input", " - accel/amdxdna: Fix use-after-free in amdxdna_gem_dmabuf_mmap()", " - accel/ivpu: Reject firmware log with size smaller than header", " - 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: 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 - only expose sysfs attributes on control interface", " - 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 firmware leak in async update", " - 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", " - tracing/user_events: Fix use-after-free in user_event_mm_dup()", " - wifi: libertas_tf: fix use-after-free in lbtf_free_adapter()", " - posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu()", " - selftests/ftrace: Drop invalid top-level local in test_ownership", " - cpu: hotplug: Preserve per instance callback errors", " - cpu: hotplug: Bound hotplug states sysfs output", " - gpio: mt7621: more robust management of IRQ domain teardown", " - gpio: tegra: do not call pinctrl for GPIO direction", " - gpio: mt7621: be sure IRQ domain is created before exposing GPIO chips", " - gpio-f7188x: Add support for NCT6126D version B", " - gpio: mt7621: avoid corruption of shared interrupt trigger state", " - gpios: palmas: add .get_direction() op", " - net: sit: require CAP_NET_ADMIN in the device netns for changelink", " - net: ethernet: ti: icssg: guard PA stat lookups", " - 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", " - selftests: net: fix file owner for broadcast_ether_dst test", " - 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", " - net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for", " changelink", " - octeontx2-af: Free BPID bitmap on setup failure", " - 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", " - platform/x86/amd/pmc: Avoid logging \"(null)\" for DMI values", " - net/sched: sch_teql: move rcu_read_lock()/spin_lock() from _bh variants", " - drm/xe/userptr: Stub notifier_lock helpers when DRM_GPUSVM=n", " - pwm: rzg2l-gpt: Fix period_ticks type from u32 to u64", " - LoongArch: Fix nr passing in set_direct_map_valid_noflush()", " - LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()", " - ipmi: Fix user refcount underflow in event delivery", " - ipmi: fix refcount leak in i_ipmi_request()", " - bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()", " - rtc: renesas-rtca3: Fix PIE clear polling condition in alarm setup error", " path", " - 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", " - fhandle: reject detached mounts in capable_wrt_mount()", " - hwmon: (max1619) add missing 'select REGMAP' to Kconfig", " - tracing/probes: Fix double addition of offset for @+FOFFSET", " - net/mlx5: HWS, fix matcher leak on resize target setup failure", " - 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", " - mm/compaction: handle free_pages_prepare() properly in compaction_free()", " - irqchip/irq-riscv-imsic-early: Fix fwnode leak on state setup failure", " - s390/monwriter: Reject buffer reuse with different data length", " - mac802154: remove interfaces with RCU list deletion", " - octeontx2-pf: fix SQB pointer leak on init failure", " - selftests: net: make busywait timeout clock portable", " - llc: fix SAP refcount leak in llc_ui_autobind()", " - ipvs: use parsed transport offset in SCTP state lookup", " - macsec: don't read an unset MAC header in macsec_encrypt()", " - dibs: loopback: validate offset and size in move_data()", " - net: macb: drop in-flight Tx SKBs on close", " - arm64: smp: Fix hot-unplug tearing by forcing unregistration", " - cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()", " - fs/resctrl: Free mon_data structures on rdt_get_tree() failure", " - fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list", " - ata: libata-core: Skip HPA resize for locked drives", " - ata: libata-core: Allow capacity transition to zero for locked drives", " - riscv: Prevent NULL pointer dereference in machine_kexec_prepare()", " - tracing/osnoise: Call synchronize_rcu() when unregistering", " - s390/diag: Add missing array_index_nospec() call to", " memtop_get_page_count()", " - s390/mm: Fix type mismatch in get_align_mask().", " - selftests/rseq: Fix a building error for riscv arch", " - 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", " - selftests/landlock: Skip scoped_signal subtest with MSG_OOB if not", " available", " - selftests/landlock: Fix screwed up pointers in the scoped_signal_test", " - mmc: sdhci-esdhc-imx: restore pinctrl before restoring ios timing on", " resume", " - powerpc/pseries: fix memory leak on krealloc failure in papr_init", " - net/mlx5: free mlx5_st_idx_data on final dealloc", " - wifi: rt2x00: avoid full teardown before work setup in probe", " - wifi: mwifiex: fix roaming to different channel in host_mlme mode", " - wifi: mac80211: fix memory leak in ieee80211_register_hw()", " - wifi: brcmfmac: cyw: fix heap overflow on a short auth frame", " - riscv: vdso: Do not use LTO for the vDSO", " - 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", " - reset: sunxi: fix memory region leak on ioremap failure", " - powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()", " - wifi: cfg80211: validate EHT MLE before MLD ID read", " - wifi: ieee80211: validate MLE common info length", " - 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", " - mmc: block: fix RPMB device unregister ordering", " - mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe()", " method", " - mmc: sdhci-esdhc-imx: remove unnecessary mmc_card_wake_sdio_irq check", " for tuning save/restore", " - mmc: sdhci-esdhc-imx: restore DLL override for DDR modes on resume", " - mmc: sdhci-esdhc-imx: fix esdhc_change_pinstate() to allow default state", " restore", " - mmc: sdhci-esdhc-imx: disable irq during suspend to fix unhandled", " interrupt", " - mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspend", " - mmc: sdhci-esdhc-imx: make non-fatal errors non-blocking in suspend", " - mmc: sdhci-esdhc-imx: fix resume error handling", " - crypto: xilinx-trng - Remove crypto_rng interface", " - 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: hid-sensor-rotation: Fix stale or zero output when reading raw", " values", " - ALSA: scarlett2: Allow selecting config_set by firmware version", " - ALSA: scarlett2: Update offsets for 2i2 Gen 4 firmware 2417", " - firmware_loader: Add cancel helper for async requests", " - ALSA: hda/tas2781: Cancel async firmware request at unbind", " - binder: Use LIST_HEAD() to initialize on stack list head", " - binder: cache secctx size before release zeroes it", " - staging: rtl8723bs: fix spaces around binary operators", " - Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister", " - Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()", " - proc: rename proc_setattr to proc_nochmod_setattr", " - usb: dwc3: Support USB3340x ULPI PHY high-speed negotiation.", " - usb: dwc3: fix dwc3_readl() and dwc3_writel() calls in dwc3_ulpi_setup()", " - usb: atm: ueagle-atm: use dev_dbg() for 'device found' message", " - usb: atm: ueagle-atm: remove function entry/exit debug messages", " - usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()", " - btrfs: remove folio parameter from ordered io related functions", " - KVM: arm64: Ensure level is always initialized when relaxing perms", " - KVM: arm64: Fix propagation of TLBI level in", " kvm_pgtable_stage2_relax_perms()", " - mm/damon/core: always put unsuccessfully committed target pids", " - mm/damon/core: trace esz at first setup", " - samples/damon/mtier: fail early if address range parameters are invalid", " - perf callchain: Handle multiple address spaces", " - soc: fsl: qe_ports_ic: Add missing cleanup on device removal", " - drm/rockchip: inno-hdmi: Switch to drmm_kzalloc()", " - accel/amdxdna: Create shared functions for AIE2 and AIE4", " - Revert \"UBUNTU: SAUCE: accel/amdxdna: Support sensors for column", " utilization\"", " - accel/amdxdna: Support sensors for column utilization", " - accel/amdxdna: Adjust size for copy_to_user()", " - accel/amdxdna: Handle DETACH_DEBUG_BO through config_debug_bo path", " - accel/amdxdna: Fix order of canceled mailbox messages", " - accel/amdxdna: Guard management mailbox channel cleanup against NULL", " pointer", " - drm/amdkfd: fix redundant MQD iterations in GFX v12.1", " - wifi: ath12k: Fix invalid IRQ requests during AHB probe", " - libbpf: Fix deduplication of typedef with base definitions", " - spi: atcspi200: Use helper function devm_clk_get_enabled()", " - spi: atcspi200: fix use-after-free when driver unbind", " - arm64: dts: rockchip: Fix vdec register blocks order on RK3576", " - arm64: dts: rockchip: Update vdec register blocks order on RK3588", " - dt-bindings: net: bluetooth: qualcomm: Fix WCN6855 regulator names", " - x86/bug: Add printf() validation to HAVE_ARCH_BUG_FORMAT_ARGS WARNs", " - arm64: dts: qcom: milos: Reduce rmtfs_mem size to 2.5MiB", " - arm64: dts: qcom: sdm845-oneplus: Drop address from framebuffer node", " - arm64: dts: qcom: sdm845-shift-axolotl: Correct touchscreen sleep state", " - soc: xilinx: Fix race condition in event registration", " - wifi: ath11k: cancel SSR work items during PCI shutdown", " - ixgbe: fix unaligned u32 access in ixgbe_update_flash_X550()", " - objtool/klp: Fix is_uncorrelated_static_local() for Clang", " - objtool/klp: Fix .data..once static local non-correlation", " - objtool/klp: Fix create_fake_symbols() skipping entsize-based sections", " - objtool/klp: Fix handling of zero-length .altinstr_replacement sections", " - objtool/klp: Fix cloning of zero-length section symbols", " - objtool/klp: Fix extraction of text annotations for alternatives", " - objtool/klp: Fix relocation conversion failures for R_X86_64_NONE", " - objtool/klp: Use sym->demangled_name for symbol_name hash", " - objtool/klp: Match symbols based on demangled_name for global variables", " - objtool: Replace iterator callback with for_each_sym_by_mangled_name()", " - objtool: Fix reloc hash collision in find_reloc_by_dest_range()", " - klp-build: Fix hang on out-of-date .config", " - klp-build: Fix checksum comparison for changed offsets", " - riscv: dts: microchip: gpio controllers on mpfs need 2 interrupt cells", " - riscv: dts: microchip: remove gpio hogs from beaglev-fire", " - wifi: cfg80211: restrict LMR feedback check to TB and non-TB ranging", " - drm/panel: Clean up SOFEF00 config dependencies", " - drm/panel: Clean up S6E3FC2X01 config dependencies", " - arm64: dts: marvell: samsung-coreprimevelte: Increase touchscreen", " voltage", " - arm64: dts: imx8mn-vhip4-evalboard-v1: Correct interrupt flags", " - arm64: dts: imx8mn-vhip4-evalboard-v2: Correct interrupt flags", " - crypto: ccp - Check for page allocation failure correctly in TIO", " - crypto: ccp - Initialize data during __sev_snp_init_locked()", " - accel/amdxdna: Fix clflush buffer size", " - ntb: Store original DMA address for future release", " - ntb: Use consistent DMA attributes when freeing DMA mappings", " - riscv: dts: spacemit: k3: add clock tree", " - dts: riscv: spacemit: correct 32k clock frequency", " - arm64: dts: qcom: sdm660: set cdsp compute-cbs' regs properly", " - arm64: dts: qcom: sdm630: set adsp compute-cbs' regs properly", " - arm64: dts: qcom: lemans: Move PCIe devices into soc node", " - sockptr: fix usize check in copy_struct_from_sockptr() for user pointers", " - arm64: dts: mediatek: mt7988a-bpi-r4pro: rework pcie gpio-hog handling", " - rhashtable: give each instance its own lockdep class", " - thermal: hwmon: Register a hwmon device for each thermal zone", " - crypto: ccp/sev-dev-tsm - bail out early when pdev->bus is NULL", " - crypto: safexcel - Fix potential memory leak in safexcel_pci_probe()", " - net/sched: add qdisc_qlen_inc() and qdisc_qlen_dec()", " - net/sched: sch_dualpi2: annotate data-races in dualpi2_dump_stats()", " - tools/rtla: Fix --dump-tasks usage in timerlat", " - rtla: Stop the record trace on interrupt", " - dm: limit target bio polling to one shot", " - selftests/bpf: Override EXTRA_LDFLAGS for static builds", " - sched/fair: Update util_est after updating util_avg during dequeue", " - hfs: fix incorrect inode ID assignment in hfs_new_inode()", " - vfio: selftests: Fix out-of-tree build with make O=", " - vfio: selftests: Allow builds when ARCH=x86", " - vfio/xe: avoid duplicate reset in xe_vfio_pci_reset_done", " - arm64: dts: qcom: kaanapali: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sdm845-xiaomi-beryllium: Correct IPA FW path", " - ASoC: mediatek: mt8189: Fix probe resource cleanup", " - drm/msm/mdss: correct UBWC programming sequences", " - tools/nolibc: stackprotector: Avoid stalling program startup if crng is", " not init yet", " - ASoC: dapm: Fix widget lookup with prefixed names across DAPM contexts", " - ACPI: PAD: Fix teardown ordering in acpi_pad_remove()", " - wifi: ath12k: fix error unwind on arch_init() failure in PCI probe", " - cpufreq: governor: Fix data races on per-CPU idle/nice baselines", " - cpufreq: governor: Fix stale prev_cpu_nice spike when enabling", " ignore_nice_load", " - dt-bindings: vendor-prefixes: Add Verbatim Corporation", " - drm/tegra: fbdev: Do not assign to struct drm_fb_helper.info", " - rust: devres: add 'static bound to Devres", " - lib/base64: validate before writing in decode tail path", " - rust: uaccess: use INLINE_COPY_TO_USER to guard copy_to_user()", " - uaccess: unify inline vs outline copy_{from,to}_user() selection", " - uaccess: minimize INLINE_COPY_USER-related ifdefery", " - crypto: ccp/tsm - Enable the root port after the endpoint", " - firmware: samsung: acpm: Add devm_acpm_get_by_phandle helper", " - firmware: samsung: acpm: remove compile-testing stubs", " - drm/msm/a8xx: Make a8xx_recover IFPC safe", " - drm/msm/a8xx: Fix RSCC offset", " - EDAC/igen6: Fix memory topology parsing for Panther Lake-H SoCs", " - arm: dts: bcm2711: Fix typo in gpio-line-names", " - arm64: dts: renesas: r8a78000: Fix GIC-720AE View 1 Redistributor", " description", " - arm64: dts: renesas: ironhide: Describe all reserved memory", " - md: replace wait loop with wait_event() in md_handle_request()", " - md/raid1,raid10: fix deadlock in read error recovery path", " - md/raid1,raid10: fix error-path detection with md_cloned_bio()", " - md/raid1,raid10: fix bio accounting for split md cloned bios", " - liveupdate: Use refcount_t for FLB reference counts", " - liveupdate: Reference count incoming FLB data", " - liveupdate: skip serialization for context-preserving kexec", " - liveupdate: fix TOCTOU race in luo_session_retrieve()", " - liveupdate: block session mutations during reboot", " - spi: imx: replace dmaengine_terminate_all() with", " dmaengine_terminate_sync()", " - wifi: ath12k: fix memory leak in ath12k_wifi7_dp_rx_h_verify_tkip_mic()", " - wifi: ath12k: fix inconsistent arvif state in vdev_create error paths", " - ACPI: button: Fix lid_device value leak past driver removal", " - drm/amd/pm: Add empty string validation to sysfs store functions", " - accel/amdxdna: Return errors for failed debug BO commands", " - mm: preserve PG_dropbehind flag during folio split", " - perf/x86/intel/uncore: Fix PCI device refcount leak in UPI discovery", " - wifi: wlcore: enable the right set of ciphers", " - cxl/test: Fix __fortify_panic", " - bpf: Take mmap_lock in zap_pages()", " - ocfs2: fix out-of-bounds write in ocfs2_remove_refcount_extent", " - cxl/pci: Fix the incorrect check of pci_read_config_word() return", " - cxl/pci: Convert PCIBIOS errors to errno on DVSEC config accesses", " - netfilter: cttimeout: detach dataplane timeout policy and repurpose", " refcount", " - arm64: dts: imx94: fix DDR PMU interrupt number", " - arm64: dts: freescale: fsl-ls1028a-tqmls1028a-mbls1028a: switch mmc", " aliases", " - selftests/bpf: Fix flaky file_reader test", " - riscv: alternative: Use IS_ENABLED() over ifdeffery for", " apply_vdso_alternatives()", " - riscv: alternative: Pass vDSO start as parameter to", " apply_vdso_alternatives()", " - riscv: alternative: Also patch the CFI vDSO", " - bpf: Verifier support for sleepable tracepoint programs", " - bpf: Reject sleepable BPF_LSM_CGROUP programs at load time", " - netfilter: flowtable: avoid num_encaps underflow on bridge VLAN untag", " - filelock: fix break_lease() stub signature for CONFIG_FILE_LOCKING=n", " - wifi: mac80211: bound S1G TIM PVB walk to the TIM element", " - ACPI: processor: Add cpuidle driver check in", " acpi_processor_register_idle_driver()", " - RDMA/nldev: Fix locking when accessing mr->pd", " - scsi: ufs: core: Handle PM commands timeout before SCSI EH", " - iommufd: Destroy the pages content after detaching from dmabuf", " - lib/test_hmm: fix memory leak in dmirror_migrate_to_system()", " - rust: kbuild: show the right `quiet_cmd_rustc_procmacrolibrary`", " - remoteproc: qcom_q6v5_wcss: drop redundant wcss_q6_bcr_reset", " - wifi: mt76: mt7996: remove redundant pdev->bus check in probe", " - wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bits", " - memory: tegra186-emc: stop borrowing MC aggregate hook for EMC", " - PM: QoS: Fix misc device registration unwind", " - btrfs: lzo: reject compressed segment that overflows the compressed", " input", " - ixgbe: do not configure xps for XDP queues", " - bpf: Cancel special fields on map value recycle", " - clocksource: move NXP timer selection to drivers/clocksource", " - [Config] Allow certain NXP timer selections for arm64", " - vduse: fix compat handling for VDUSE_IOTLB_GET_FD/VDUSE_VQ_GET_INFO", " - iomap: pass the correct len to fserror_report_io in __iomap_write_begin", " - ASoC: cs35l56: Prevent double-free of debugfs", " - ASoC: cs35l56: Cleanup if component_probe fails", " - hwmon: (gpd-fan): drop global driver data and use per-device allocation", " - hwmon: (gpd-fan): Initialize EC before registering hwmon device", " - hwmon: (gpd-fan): fix race condition between device removal and sysfs", " access", " - ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT", " - cxl/test: Verify cmd->size_in before accessing payload", " - m68k: mcf5441x: fix clocks numbering", " - pinctrl: airoha: an7583: add missed gpio32 pin group", " - pinctrl: airoha: an7583: fix misprint in gpio19 pinconf", " - pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin", " function", " - pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin", " function", " - pinctrl: airoha: fix pwm pin function for an7581 and an7583", " - pinctrl: airoha: an7583: fix gpio21 pin group", " - pinctrl: airoha: an7583: add missed gpio22 pin group", " - pinctrl: airoha: an7583: fix phy1_led1 pin function", " - pinctrl: airoha: an7583: remove undefined groups from pcm_spi pin", " function", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_setup() for non-", " serdev device", " - Bluetooth: btintel: Replace CNVi id with hardware variant", " - Bluetooth: btintel: Add DSBR support for ScP2 onwards", " - Bluetooth: btintel_pcie: Load IOSF debug regs by controller variant", " - ASoC: cs35l56: Fix wrong error test on simple_write_to_buffer()", " - ASoC: SOF: Intel: select SND_SOC_SDW_UTILS=y from", " SND_SOC_SOF_HDA_GENERIC=y", " - ASoC: meson: aiu: Validate written enum values", " - ASoC: topology: Check PCM and DAI name strings before use", " - ipv4: fib: Don't dump dying fib_info in fib_leaf_notify().", " - iommu/dma-iommu: Fix wrong scatterlist length assignment in P2PDMA path", " - iommufd: Clarify IOAS_MAP_FILE dma-buf support", " - cxl/region: Fill first free targets[] slot during auto-discovery", " - vfio: selftests: Ensure libvfio output dirs are always created", " - cxl/region: Block region delete during region creation", " - cxl/region: Resolve region deletion races", " - cxl/memdev: Pin parents for entire memdev lifetime", " - net: airoha: Fix error handling in airoha_ppe_flush_sram_entries()", " - netfilter: nft_fwd_netdev: use recursion counter in neigh egress path", " - netfilter: nf_dup_netdev: add nf_dev_xmit_recursion*() helpers and use", " them", " - geneve: Fix off-by-one comparing with GRO_LEGACY_MAX_SIZE", " - smb: client: fix conflicting option validation for new mount API", " - btrfs: Drop WQ_PERCPU from ordered_flags in btrfs_init_workqueues()", " - bpf: Guard __get_user acesss with access_ok for uprobe_multi data", " - net: ti: icssg-prueth: Fix AF_XDP fill ring alloc and wakeup condition", " - net: ti: icssg: Use undirected TX tag for native XDP in HSR offload mode", " - net: ti: icssg: Use undirected TX tag for XDP zero copy in HSR offload", " mode", " - RDMA/bnxt_re: Free CQ toggle page after firmware teardown", " - RDMA/bnxt_re: Reject GET_TOGGLE_MEM when toggle page was not allocated", " - RDMA/hns: Fix memory leak of bonding resources", " - mfd: bd72720: Drop BUCK11 ID", " - 9p: Add missing read barrier in virtio zero-copy path", " - perf dwarf-aux: Fix libdw segmentation fault in cu_walk_functions_at", " - perf dwarf-aux: Fix libdw API contract violations", " - perf srcline: Introduce inline_node__clear_frames()", " - perf libdw: Fix libdw API contract violations and memory leaks", " - perf probe-finder: Fix libdw API contract violations", " - perf annotate-data: Fix libdw API contract violations", " - coresight: tmc: Fix overflow when calculating is bigger than 2GiB", " - perf tool: Fix missing schedstat delegates and dont_split_sample_group", " in delegate_tool", " - PCI: intel-gw: Move interrupt enable to own function", " - PCI: intel-gw: Enable clock before PHY init", " - PCI: intel-gw: Add .start_link() callback", " - bus: mhi: ep: Add missing state_lock protection for mhi_state access", " - PCI: dwc: Apply ECRC workaround for DesignWare cores prior to 5.10a", " - PCI: qcom: Set max OPP before DBI access during resume", " - perf pmu-events AMD: Switch l2_itlb_misses to", " bp_l1_tlb_miss_l2_tlb_miss.all", " - perf unwind: Refactor get_entries to allow dynamic libdw/libunwind", " selection", " - coresight: Handle helper enable failure properly", " - mailbox: don't free the channel if the startup callback failed", " - PCI/pwrctrl: Lock device when calling device_is_bound()", " - coresight: platform: defer connection counter increment until alloc", " succeeds", " - platform/x86: classmate-laptop: Address memory leaks on driver removal", " - clk: microchip: mpfs-ccc: fix peripheral driver registration failures", " after oob fix", " - perf sample: Add evsel to struct perf_sample", " - perf event: Fix size of synthesized sample with branch stacks", " - perf inject: Fix itrace branch stack synthesis", " - gpib: cb7210: Fix region leak when request_irq fails", " - timers/migration: Update stale @online doc to @available", " - clk: spacemit: k3: Switch to pll2_d6 as parent for PCIe clock", " - clk: spacemit: k3: Fix PCIe clock register offset", " - fs/ntfs3: fix wrong LCN in run_remove_range() when splitting a run", " - ntfs3: Allocate iomap inline_data using alloc_page", " - perf sample: Add file_offset field to struct perf_sample", " - perf sched: Replace BUG_ON on invalid CPU with graceful skip", " - perf sched: Fix NULL dereference in latency_runtime_event", " - perf sched: Fix comp_cpus heap overflow with cross-machine recordings", " - perf tools: Guard remaining test_bit calls from OOB sample CPU", " - perf sched: Fix thread reference leaks in timehist_get_thread()", " - perf sched: Use is_idle_sample() for idle thread runtime cast guard", " - perf sched: Fix thread reference leak in idle hist processing", " - perf sched: Free callchain nodes in idle thread cleanup", " - docs: memfd_preservation: fix rendering of ABI documentation", " - virtio: add missing kernel-doc for map and vmap members", " - fs/ntfs3: prevent potential lcn remains uninitialized", " - perf tools: NULL bitmap pointers after bitmap_free()", " - perf tools: Use scnprintf() in build_id__snprintf() and hwmon", " read_events()", " - perf data convert json: Fix addr_location leak on time-filtered samples", " - perf tools: Use mkostemp() for O_CLOEXEC on temporary files", " - phy: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put", " in reset", " - sparc: Avoid -Wunused-but-set-parameter in clear_user_page()", " - apparmor: release exe file resources on path failure", " - apparmor: remove unnecessary goto and associated label", " - apparmor: Fix inverted comparison in cache_hold_inc()", " - i3c: mipi-i3c-hci: Fix suspend behavior when bus disable falls back to", " software reset", " - i3c: master: Serialize i3c_set_hotjoin() with the maintenance lock", " - i3c: mipi-i3c-hci: Fix race in i3c_hci_addr_to_dev()", " - perf maps: Add maps__mutate_mapping", " - perf c2c: Free format list entries when releasing c2c hist entries", " - regcache: Do not overwrite error code when finalizing cache after error", " - erofs: call erofs_exit_ishare() before rcu_barrier()", " - perf c2c: Free format list entries when c2c_hists__init() fails", " - perf c2c: Fix hist entry and format list leaks in c2c_he_free()", " - drm/amd/display: Skip PHY SSC reduction on some 8K panels", " - net: ethernet: mtk_eth_soc: fix supported_interface set after", " phylink_create", " - selftests/ftrace: Fix trace_marker_raw test on 64K page kernels", " - octeontx2-af: npc: Log successful MCAM drop-on-non-hit install at debug", " level", " - netconsole: don't drop the last byte of a full-sized message", " - eth: fbnic: take netif_addr_lock_bh() around rx mode address programming", " - arm64: static_call: include asm/insns.h", " - md/raid1: fix writes_pending and barrier reference leaks on write", " failures", " - md/raid10: fix writes_pending leak on write request failures", " - md/raid10: fix writes_pending and barrier reference leaks on discard", " failures", " - netfilter: ipset: Don't use test_bit() in lockless RCU readers in bitmap", " types", " - selftests/mm: fix hugetlb pathname construction in", " charge_reserved_hugetlb.sh", " - selftests/mm: run_vmtests.sh: free memory if available memory is low", " - selftests/mm: move hwpoison setup into run_test() and silence modprobe", " output for memory-failure category", " - selftests/mm: remove hardcoded THP sizing assumptions in hmm tests", " - net: dst_metadata: fix false-positive memcpy overflow in tun_dst_unclone", " - bpf: Fix partial copy of non-linear test_run output", " - bpf: Fix BPF_PROG_ASSOC_STRUCT_OPS last field check", " - erofs: handle 48-bit blocks_hi for compressed inodes", " - ASoC: cs530x: Fix expected MCLK rates for CS5302/4/8", " - PCI: endpoint: pci-epf-vntb: Document legacy MSI doorbell offset", " - PCI: endpoint: pci-epf-vntb: Defer pci_epc_raise_irq() out of atomic", " context", " - PCI: endpoint: pci-epf-vntb: Report 0-based doorbell vector via", " ntb_db_event()", " - e1000e: Reconfigure PLL clock gate timeout and re-enable K1 on Meteor", " Lake", " - bpf: Guard conntrack opts error writes", " - selftests/bpf: Cover small conntrack opts error writes", " - netfilter: nf_conntrack_helper: dynamically allocate struct", " nf_conntrack_helper", " - netfilter: nf_conntrack_pptp: move GRE specific cleanup to GRE tracker", " - netfilter: nf_conntrack_gre: fix gre keymap list corruption", " - netfilter: conntrack: check NULL when retrieving ct extension", " - netfilter: nf_conntrack_expect: use conntrack GC to reap expectations", " - netfilter: nf_conntrack_expect: store master_tuple in expectation", " - netfilter: nf_conntrack_expect: run expectation eviction with no helper", " - netfilter: nft_ct: expectation timeouts are passed in milliseconds", " - netfilter: nf_conntrack_helper: cap maximum number of expectation at", " helper registration", " - cpuidle: Allow exit latency to exceed target residency", " - ASoC: SDCA: Validate written enum value in ge_put_enum_double()", " - ASoC: rt5575: Use __le32 for SPI burst write address", " - PCI: endpoint: pci-epf-vntb: Exclude reserved slots from db_valid_mask", " - net: ti: icssg: Fix XSK zero copy TX during application wakeup", " - net: lwtunnel: Drop skb metadata before LWT encapsulation", " - sctp: fix err_chunk memory leaks in INIT handling", " - net: dsa: mxl862xx: avoid unaligned 16-bit access in api_wrap", " - octeontx2-af: fix CGX debugfs RVU AF PCI reference leaks", " - geneve: gate GRO hint in geneve_gro_complete() on gs->gro_hint", " - geneve: validate inner network offset in geneve_gro_complete()", " - tools: ynl: build archives with $(AR)", " - net: enetc: fix potential divide-by-zero when num_vsi is zero", " - udp_tunnel: Pass struct sock to setup_udp_tunnel_sock().", " - tipc: avoid busy looping in tipc_exit_net()", " - bpf: Mask pseudo pointer values in verifier logs", " - bpf: Fix insn_aux_data leak on verifier err_free_env path", " - hwmon: (pmbus/core) Add support for NVIDIA nvidia195mv mode", " - hwmon: (pmbus/core) honor vrm_version in pmbus_data2reg_vid()", " - gpio: shared-proxy: always serialize with a sleeping mutex", " - drm/panthor: Always use the IRQ-safe variant when acquiring the fence", " lock", " - drm/panthor: Keep the reset work disabled until everything is", " initialized", " - drm/panthor: Fix panthor_pwr_unplug()", " - spi: rzv2h-rspi: Fix DMA transfer error handling for signal interruption", " - xen/pvcalls: bound backend response req_id before indexing rsp[]", " - afs: Remove setting of AS_RELEASE_ALWAYS for symlinks and mountpoints", " - afs: Fix directory inode initialisation order", " - afs: Use scoped_seqlock_read() rather than manually doing seqlock stuff", " - afs: Fix leak of ungot volume", " - iomap: release pages on atomic dio size mismatch", " - cachefiles: Fix double unlock in nomem_d_alloc error path", " - cachefiles: Fix file burial to take lock when unsetting S_KERNEL_FILE", " - drm/imagination: Fix returned size for DRM_IOCTL_PVR_DEV_QUERY", " - iio: dac: mcp47feb02: Fix passing uninitialized vref1_uV for no Vref1", " case", " - net/mlx5: LAG, replace pf array with xarray", " - net/mlx5: LAG, use xa_alloc to manage LAG device indices", " - net/mlx5: Lag: refactor representor reload handling", " - net/mlx5: E-Switch, add representor lifecycle lock", " - net/mlx5: Lag, avoid LAG and representor lock cycles", " - net/mlx5: LAG, factor out shared FDB code into dedicated file", " - net/mlx5: LAG, replace peer count check with direct peer lookup", " - net/mlx5: LAG, prepare for SD device integration", " - net/mlx5: LAG, replace mlx5_get_dev_index with LAG sequence number", " - net/mlx5: LAG, extend shared FDB API with group_id filter", " - net/mlx5: LAG, Fix off-by-one in single-FDB error rollback", " - ksmbd: fix multichannel binding and enforce channel limit", " - smb: client: preserve leading slash for POSIX absolute symlink targets", " - gpio: shared: make the voting mechanism adaptable", " - drm/i915/ltphy: Fix SSC Enablement bit in PORT_CLOCK_CTL", " - Bluetooth: 6lowpan: avoid untracked enable work", " - Bluetooth: btintel_pcie: Support Product level reset", " - [Config] Make BT_INTEL_PCIE depend on ACPI", " - Bluetooth: btintel_pcie: Add support for smart trigger dump", " - Bluetooth: btintel_pcie: Separate coredump work from RX work", " - Bluetooth: btintel_pcie: Refactor FLR to use device_reprobe()", " - Bluetooth: ISO: fix malformed ISO_END/CONT handling", " - accel/amdxdna: Prevent PM resume deadlock in hwctx_sync_debug_bo()", " - accel/amdxdna: Fix VMA access race", " - net: rnpgbe: fix mailbox endianness and remove pointer casts", " - drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE", " - smb: client: fix busy dentry warning on unmount after DIO", " - drm/fb-helper: Only consider active CRTCs for vblank sync", " - ethtool: rss: Fix hfunc and input_xfrm parsing on big endian", " - drm/imagination: make pvr_fw_trace_init_mask_ops static", " - VDUSE: avoid leaking information to userspace", " - ASoC: SOF: ipc4-control: Validate notification payload size", " - arm64: dts: renesas: ironhide: Describe inline ECC carveouts", " - arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers", " - KVM: s390: vsie: Fix allocation of struct vsie_rmap", " - KVM: s390: vsie: Add missing radix_tree_preload() in", " _gaccess_shadow_fault()", " - KVM: s390: Add some useful mask macros", " - KVM: s390: vsie: Fix rmap handling in _do_shadow_crste()", " - KVM: s390: vsie: Fix redundant rmap entries", " - KVM: s390: vsie: Use mmu cache to allocate rmap", " - KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory", " - KVM: TDX: Reject concurrent change to CPUID entry count", " - ASoC: SOF: topology: fix memory leak in snd_sof_load_topology", " - netfilter: nft_fib: reject fib expression on the netdev egress hook", " - netfilter: nf_conntrack_sip: remove net variable shadowing", " - netfilter: nf_conntrack_sip: validate skb_dst() before accessing it", " - gpu/buddy: bail out of try_harder when alignment cannot be honoured", " - backlight: ktd2801: Enable BL_CORE_SUSPENDRESUME", " - cxl: Fix CXL_HEADERLOG_SIZE to match RAS Capability size", " - pinctrl: renesas: rzg2l: Use -ENOTSUPP instead of -EOPNOTSUPP", " - remoteproc: xlnx: Check remote core state", " - mm/sparse-vmemmap: fix vmemmap accounting underflow", " - mm/huge_memory: preserve pmd_swp_uffd_wp on device-private PMD downgrade", " - fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race", " - fs/proc/task_mmu: do not warn on seeing non-migration pmd entry", " - kho: make sure scratch size is always aligned by CMA_MIN_ALIGNMENT_BYTES", " - mtd: maps: vmu-flash: fix fault in unaligned fixup", " - dmaengine: dw-edma-pcie: Reject devices without driver data", " - dmaengine: sh: rz-dmac: Move interrupt request after everything is set", " up", " - platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8D26)", " - platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8E35)", " - spi: imx: reconfigure for PIO when DMA cannot be started", " - ovl: use linked upper dentry in copy-up tmpfile", " - can: bcm: add locking when updating filter and timer values", " - can: bcm: extend bcm_tx_lock usage for data and timer updates", " - can: bcm: fix CAN frame rx/tx statistics", " - can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()", " - can: bcm: fix stale rx/tx ops after device removal", " - can: bcm: track a single source interface for ANYDEV timeout/throttle", " ops", " - can: bcm: validate frame length in bcm_rx_setup() for RTR replies", " - can: bcm: add missing device refcount for CAN filter removal", " - selftests/bpf: Cover negative buffer pointer offsets", " - dm: avoid leaking the caller's thread keyring via the table device file", " - dma-buf: protected fence ops by RCU v8", " - dma-fence: use correct callback in dma_fence_timeline_name()", " - accel/amdxdna: reject command submission on devices without a submit op", " - accel/amdxdna: reject user command submission without a command BO", " - accel/amdxdna: Use caller client for debug BO sync", " - fs/resctrl: Fix use-after-free during unmount", " - mmc: vub300: fix use-after-free on probe failure", " - octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF", " - ksmbd: fix stack buffer overflow in multichannel session-key copy", " - netfilter: nfnetlink_cthelper: cap to maximum number of expectation per", " master", " - netfilter: nfnetlink_cthelper: cap to maximum number of expectation per", " master on updates", " - riscv: vdso: Always declare vdso_start symbols", " - ata: libata-core: Add NOLPM quirk for PNY CS900 1TB SSD", " - ata: libata-core: Reject an invalid concurrent positioning ranges count", " - net: ipa: fix SMEM state handle leaks in SMP2P init", " - amdkfd: properly free secondary context id", " - pmdomain: imx93-blk-ctrl: Extract PHY as shared domain for DSI/CSI", " - pmdomain: mediatek: Fix possible nullptr KP in HWV cleanup/on-check", " - arch/riscv: vdso: remove CFI landing pad from rt_sigreturn", " - reset: imx7: Correct polarity of MIPI CSI resets on i.MX8MQ", " - powerpc/uaccess: correct check for CONFIG_PPC_E500 in", " mask_user_address()", " - wifi: mac80211: validate extension-frame layout before RX", " - xfs: factor out a xfs_zone_mark_free helper", " - xfs: add newly added RTGs to the free pool in growfs", " - liveupdate: validate session type before performing operation", " - posix-timers: Expand timer_[re]arm() callbacks with a boolean return", " value", " - posix-cpu-timers: Prevent UAF caused by non-leader exec() race", " - Revert \"gpib: cb7210: Fix region leak when request_irq fails\"", " - Upstream stable to v6.18.40, v7.1.5", " * Resolute update: upstream stable patchset 2026-08-20 (LP: #2164666) //", " CVE-2023-20585", " - 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", " * [Regression] Laptop fails to power off completely when HDMI is connected", " in kernel 7.0.0-28 (LP: #2163121) // CVE-2026-68364", " - drm/amd/display: fix NULL ptr deref in ISM delayed work", " - drm/amd/display: Fix ISM teardown crash from NULL dc dereference", " - drm/amd/display: Fix ISM dc_lock deadlock during suspend", " * CVE-2026-72064", " - net: mana: Sync page pool RX frags for CPU", " * CVE-2026-72065", " - net: mana: Validate the packet length reported by the NIC", " * CVE-2026-72098", " - dm-verity-fec: replace {MAX,MIN}_RSN with {MIN,MAX}_ROOTS", " - dm-verity: fix buffer overflow in FEC calculation", " * CVE-2026-72248", " - netfilter: flowtable: support IPIP tunnel with direct xmit", " - netfilter: flowtable: use correct direction to set up tunnel route", " * CVE-2026-72249", " - netfilter: flowtable: use dst in this direction when pushing IPIP header", " * CVE-2026-72287", " - KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\"", " checks", " * CVE-2026-72329", " - net/liquidio: drop cached VF pci_dev LUT", " * CVE-2026-72355", " - netfs: Fix barriering when walking subrequest list", " * CVE-2026-72412", " - s390/mm: Fix handling of _PAGE_UNUSED pte bit", " * CVE-2026-72417", " - netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto()", " * CVE-2026-72442", " - netfilter: flowtable: fix and simplify IP6IP6 tunnel handling", " * CVE-2026-72463", " - xfrm: Fix dev use-after-free in xfrm async resumption", " * CVE-2026-72477", " - fs/ntfs3: call _ntfs_bad_inode() when failing to rename", " * CVE-2026-72493", " - net: serialize netif_running() check in enqueue_to_backlog()", " * CVE-2026-72494", " - RDMA/irdma: Replace waitqueue and flag with completion", " * CVE-2026-72496", " - RDMA/bnxt_re: Proper rollback if the ioremap fails", " * CVE-2026-74269", " - bnxt: fix head underflow on XDP head-grow", " * CVE-2026-74350", " - ocfs2: validate fast symlink target during inode read", " * CVE-2026-72495", " - RDMA/bnxt_re: Avoid repeated requests to allocate WC pages", " * CVE-2026-72501", " - RDMA/bnxt_re: Initialize dpi variable to zero", " * CVE-2026-72278", " - KVM: arm64: nv: Re-translate VNCR before injecting abort", " * CVE-2026-68083", " - ksmbd: fix path resolution in ksmbd_vfs_kern_path_create", " * CVE-2026-68457", " - ksmbd: use opener credentials for FSCTL mutations", " * CVE-2026-68476", " - ipvs: reload ip header after head reallocation", " * CVE-2026-68477", " - ipvs: fix more places with wrong ipv6 transport offsets", " * CVE-2026-72014", " - drbd: reject data replies with an out-of-range payload size", " * CVE-2026-72020", " - ipvs: reset full ip_vs_seq structs in ip_vs_conn_new", " * CVE-2026-72033", " - orangefs: keep the readdir entry size 64-bit in fill_from_part()", " * CVE-2026-72041", " - espintcp: use sk_msg_free_partial to fix partial send", " * CVE-2026-72046", " - gve: fix header buffer corruption with header-split and HW-GRO", " * CVE-2026-72069", " - locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()", " * CVE-2026-72083", " - scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE", " * CVE-2026-72084", " - scsi: target: Bound PR-OUT TransportID parsing to the received buffer", " * CVE-2026-72085", " - scsi: xen: scsiback: Free unsubmitted command instead of double-putting", " it", " * CVE-2026-72129", " - nvmet-rdma: handle inline data with a nonzero offset", " * CVE-2026-72130", " - nvmet-auth: reject short AUTH_RECEIVE buffers", " * CVE-2026-64551", " - sctp: validate STALE_COOKIE cause length before reading staleness", " * CVE-2026-72137", " - xfrm: nat_keepalive: avoid double free on send error", " * CVE-2026-72139", " - tcp: defer md5sig_info kfree past RCU grace period in tcp_connect", " * CVE-2026-72191", " - ntfs3: validate split-point offset in indx_insert_into_buffer", " * CVE-2026-72192", " - ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head", " * CVE-2026-72194", " - fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow", " * CVE-2026-72217", " - SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing", " * CVE-2026-72220", " - sunrpc: harden rq_procinfo lifecycle to prevent double-free", " * CVE-2026-72221", " - sunrpc: wait for in-flight TLS handshake callback when cancel loses race", " * CVE-2026-72222", " - sunrpc: pin svc_xprt across the asynchronous TLS handshake callback", " * CVE-2026-72226", " - batman-adv: tt: prevent TVLV OOB check overflow", " * CVE-2026-72234", " - batman-adv: access unicast_ttvn skb->data only after skb realloc", " * CVE-2026-72251", " - netfilter: nf_nat_sip: reload possible stale data pointer", " * CVE-2026-72277", " - KVM: arm64: nv: Inject SEA if kvm_translate_vncr() can't resolve PFN", " - KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory", " * CVE-2026-72279", " - KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR", " * CVE-2026-72288", " - KVM: arm64: vgic: Handle race between interrupt affinity change and LPI", " disabling", " * CVE-2026-72289", " - KVM: arm64: vgic: Check the interrupt is still ours before migrating it", " * CVE-2026-72296", " - net: ife: require ETH_HLEN to be pullable in ife_decode()", " * CVE-2026-72299", " - tipc: restrict socket queue dumps in enqueue tracepoints", " * CVE-2026-72317", " - SUNRPC: pin upper rpc_clnt across the TLS connect_worker", " * CVE-2026-72318", " - cifs: validate DFS referral string offsets", " * CVE-2026-72319", " - ipvs: fix PMTU for GUE/GRE tunnel ICMP errors", " - ipvs: ensure inner headers in ICMP errors are in headroom", " * CVE-2026-72320", " - netfilter: nft_lookup: fix catchall element handling with inverted", " lookups", " * CVE-2026-72322", " - ipv6: mcast: Fix potential UAF in MLD delayed work", " * CVE-2026-72323", " - ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()", " * CVE-2026-64541", " - net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket", " * CVE-2026-72339", " - qede: fix off-by-one in BD ring consumption on build_skb failure", " * CVE-2026-72348", " - netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop", " * CVE-2026-72351", " - gue: validate REMCSUM private option length", " * CVE-2026-72366", " - netfs: Fix netfs_create_write_req() to handle async cache object", " creation", " * CVE-2026-72381", " - ksmbd: fix use-after-free of fp->owner.name in durable handle owner", " check", " * CVE-2026-72393", " - eth: fbnic: don't cache shinfo across skb realloc", " * CVE-2026-72398", " - sctp: add INIT verification after cookie unpacking", " * CVE-2026-72399", " - net: enetc: check the number of BDs needed for xdp_frame", " * CVE-2026-64530", " - net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle", " * CVE-2026-72422", " - ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2", " NEGOTIATE", " * CVE-2026-72429", " - ipv6: ioam: fix type confusion of dst_entry", " * CVE-2026-72436", " - 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", " * CVE-2026-72451", " - xfrm: Fix xfrm state cache insertion race", " * CVE-2026-72466", " - xprtrdma: Fix bcall rep leak and unbounded peek", " * CVE-2026-72472", " - nfs: use nfsi->rwsem to protect traversal of the file lock list", " * CVE-2026-72473", " - 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", " * CVE-2026-72491", " - net/9p: fix race condition on rdma->state in trans_rdma.c", " * CVE-2026-72495 // CVE-2026-72501", " - RDMA/bnxt_re: Move the UAPI methods to a dedicated file", " * CVE-2026-74255", " - tipc: fix UAF in tipc_l2_send_msg()", " * CVE-2026-74267", " - net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek", " before restoring qlen", " * CVE-2026-74268", " - tcp: clear sock_ops cb flags before force-closing a child socket", " * CVE-2026-74287", " - sctp: validate embedded address parameter length", " * CVE-2026-74310", " - vhost/net: complete zerocopy ubufs only once", " * CVE-2026-74345", " - RDMA/siw: Fix endpoint/socket association handling", " * CVE-2026-74361", " - nvme: fix FDP fdpcidx bounds check", " * CVE-2026-74376", " - md/raid10: reset read_slot when reusing r10bio for discard", " * CVE-2026-74384", " - nvme-multipath: fix flex array size in struct nvme_ns_head", " * CVE-2026-74394", " - RDMA/srpt: fix integer overflow in immediate data length check", " * CVE-2026-74398", " - ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD", " * CVE-2026-74401", " - dlm: fix add msg handle in send_queue ordered", " * CVE-2026-74406", " - vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().", " * CVE-2026-74427", " - afs: Fix netns teardown to cancel the preallocation charger", " - afs: Fix further netns teardown to cancel the preallocation charger", " * CVE-2026-74428", " - rxrpc: Fix double unlock in rxrpc_recvmsg()", " * CVE-2026-74433", " - rxrpc: Fix UAF in rxgk_issue_challenge()", " * CVE-2026-74434", " - rxrpc: Don't move a peeked OOB message onto the pending queue", " * CVE-2026-74436", " - rxrpc: serialize kernel accept preallocation with socket teardown", " * CVE-2026-64535", " - nvmet-tcp: Fix potential UAF when ddgst mismatch", " * CVE-2026-74439", " - iommu/vt-d: Clear Present bit before tearing down scalable-mode context", " entry", " * CVE-2026-64534", " - nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error", " path", "" ], "package": "linux-riscv-7.0", "version": "7.0.0-38.38.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2165483, 2165484, 2165407, 2166547, 2166443, 2166356, 2165872, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165407, 2165040, 2161748, 2163508, 2163214, 2162904, 2162045, 2164967, 2160082, 2164504, 2156316, 2164716, 2164516, 2163375, 2162803, 2163062, 2132119, 2163293, 2160200, 2158858, 2162704, 2162695, 2164666, 2164666, 2163121 ], "author": "Sarah Emery ", "date": "Sun, 27 Sep 2026 00:11:21 +0200" } ], "notes": "linux-image-7.0.0-38-generic version '7.0.0-38.38.1~24.04.1' (source package linux-riscv-7.0 version '7.0.0-38.38.1~24.04.1') was added. linux-image-7.0.0-38-generic version '7.0.0-38.38.1~24.04.1' has the same source package name, linux-riscv-7.0, as removed package linux-headers-7.0.0-34-generic. As such we can use the source package version of the removed package, '7.0.0-34.34.1~24.04.1', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-modules-7.0.0-38-generic", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": null }, "to_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-38.38.1~24.04.1", "version": "7.0.0-38.38.1~24.04.1" }, "cves": [ { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-68105", "url": "https://ubuntu.com/security/CVE-2026-68105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix kernel panic during driver load failure Avoid kernel panic if MES init fails during driver load. The KIQ ring is falsely marked as ready as ASICs that use MES, KIQ is owned by MES. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] Call Trace: gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280 __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53 (cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68109", "url": "https://ubuntu.com/security/CVE-2026-68109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68114", "url": "https://ubuntu.com/security/CVE-2026-68114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit e4d99e04b2e9b13b97d3b17804c735f62689db23)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68431", "url": "https://ubuntu.com/security/CVE-2026-68431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate minimum PDU size for transform requests The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68138", "url": "https://ubuntu.com/security/CVE-2026-68138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: serialize qdisc_rtab_list against concurrent get/put qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68082", "url": "https://ubuntu.com/security/CVE-2026-68082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix two unsafe bare decodes in decode_lockers() decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-08 10:16:00 UTC" }, { "cve": "CVE-2026-68159", "url": "https://ubuntu.com/security/CVE-2026-68159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68163", "url": "https://ubuntu.com/security/CVE-2026-68163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_vma_mapped: fix device-private PMD handling Commit 65edfda6f3f2 (\"mm/rmap: extend rmap and migration support device-private entries\") introduced the concept of device-private PMD entries, but did not correctly update the rmap walk code to account for them. As a result, when page_vma_mapped_walk() encounters device-private PMD entries, it takes no action other than to acquire the PMD lock and exit. However this is highly problematic for two reasons - firstly, device private entries possess a PFN so check_pmd() needs to be called to ensure an overlapping PFN range. Secondly, and more importantly, if PVMW_MIGRATION is set the caller assumes the returned entry is a migration entry, resulting in memory corruption when the caller tries to interpret the device private entry as such. In addition, commit 146287290023 (\"mm/huge_memory: implement device-private THP splitting\") allowed device private PMDs to be split like THP mappings, but again did not update this code path. As a result, we might race a PMD split prior to acquiring the PMD lock. This patch addresses all of these issues by invoking check_pmd(), ensuring PMVW_MIGRATION is not set and checks whether a split raced us we do for PMD THP and migration entries. Instead of checking for a subset of the cases after taking the pmd_lock(), put device-private along with pmd_trans_huge() and pmd_is_migration_entry(). Also remove thp_migration_supported() as it is already guarded by pmd_is_migration_entry(). [akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68166", "url": "https://ubuntu.com/security/CVE-2026-68166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: prevent registration of special VMAs Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68170", "url": "https://ubuntu.com/security/CVE-2026-68170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix stale skb->sk reference on subflow close The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68177", "url": "https://ubuntu.com/security/CVE-2026-68177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Delay module ref count for \"enable_event\" trigger Triggers are now delayed from freeing, but can still be triggered until after the RCU grace period has ended. The freeing of the enable_event data is put into the private_data_free() callback, but the put of the module refcount is done immediately. It is possible that if a module is removed that has an event that would enable (or disable) it is still active, it can read the data of the module after it is removed causing a use-after-free bug. Move the trace_event_put_ref() that releases the module into the delayed callback so that the module can not be removed until any reference to its events are finished.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68191", "url": "https://ubuntu.com/security/CVE-2026-68191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix NULL pointer dereference in rhash table destroy When unbinding the ath12k driver, kernel NULL pointer dereferences occur in irq_work_sync() called from rhashtable_destroy(). Two hash tables are affected: 1. ath12k_link_sta hash table in ath12k_base 2. ath12k_dp_link_peer hash table in ath12k_dp The issue happens because the destroy functions are called unconditionally in cleanup paths, but the hash tables are only initialized late in their respective init functions. If the device was never fully started or if the init functions failed before initializing the hash tables, the pointers will be NULL. The issues are always reproducible from a VM because the MSI addressing initialization is failing. Call trace for ath12k_link_sta_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_link_sta_rhash_tbl_destroy+0x19/0x40 [ath12k] ath12k_core_stop+0xe/0x80 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Call trace for ath12k_dp_link_peer_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_dp_link_peer_rhash_tbl_destroy+0x29/0x50 [ath12k] ath12k_dp_cmn_device_deinit+0x21/0x140 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Fix this by adding NULL checks before calling rhashtable_destroy() in both destroy functions. The NULL check approach was chosen because the rhashtable pointer serves as the initialization state indicator. The init can fail at various points, leaving some components uninitialized. Checking the pointer directly is simpler than adding separate state flags that would need synchronization.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64586", "url": "https://ubuntu.com/security/CVE-2026-64586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: drain bus_reset work on device removal brcmf_fw_crashed() and the debugfs \"reset\" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs \"reset\" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. 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-68208", "url": "https://ubuntu.com/security/CVE-2026-68208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: Fix the error code of devm_kzalloc() in vip_probe_slice() In vip_probe_slice(), the error check for devm_kzalloc() incorrectly uses PTR_ERR_OR_ZERO() which returns 0 for NULL pointer. Return -ENOMEM for devm_kzalloc() failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68224", "url": "https://ubuntu.com/security/CVE-2026-68224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mali-c55: Fix possible ERR_PTR in enable_streams The media_pad_remote_pad_unique() function returns either a valid pointer or an ERR_PTR() on failure (-ENOTUNIQ if multiple links are enabled, -ENOLINK if no connected pad is found). The return value was assigned directly to isp->remote_src and dereferenced in the next line without checking for errors, which could lead to an ERR_PTR dereference. Add proper error checking with IS_ERR() before dereferencing the pointer. Also set isp->remote_src to NULL on error to maintain consistency with other error paths in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68237", "url": "https://ubuntu.com/security/CVE-2026-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: fix indefinite fence wait during GPU reset pre_reset only force-completes fences of MAPPED queues. A queue in any other state (e.g. mid-eviction) keeps its last_fence pending; after a GPU reset that fence never signals, so the eviction/suspend worker and process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and wedge the machine: INFO: task kworker/6:28 blocked for more than 120 seconds. Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu] Call Trace: dma_fence_wait_timeout+0x7e/0x130 amdgpu_userq_evict+0x67/0x140 [amdgpu] amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu] process_scheduled_works+0xa6/0x420 Force-complete every queue's fence regardless of state. The unmap and mark-hung step stays gated on MAPPED, since unmapping a queue that is not mapped is invalid. (cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68240", "url": "https://ubuntu.com/security/CVE-2026-68240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: publish dpagemap early to avoid device mapping leak on error drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68242", "url": "https://ubuntu.com/security/CVE-2026-68242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix NULL deref on sched_engine alloc failure Avoid using intel_context_put() before intel_context_init() in execlists_create_virtual() as the kref_put() inside would lead to NULL deref on the IOCTL path when sched_engine allocation fails. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68254", "url": "https://ubuntu.com/security/CVE-2026-68254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: require valid min/max vfreq for VRR Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68436", "url": "https://ubuntu.com/security/CVE-2026-68436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use kvzalloc to allocate struct dc struct dc has grown large over time (most of it the two inlined dc_scratch_space copies) and now sits close to the page allocator's 4 MiB contiguous allocation limit. Its actual size is not fixed by the source alone, it also depends on the compiler and the .config, so it can easily cross 4 MiB, e.g. with a newer GCC or a config change. dc_create() allocates it with kzalloc(). Once struct dc exceeds 4 MiB the request is rounded up to order 11 (8 MiB), which is above MAX_PAGE_ORDER, so the page allocator warns and returns NULL. dc_create() then fails, DM init fails and amdgpu probe aborts with -EINVAL: WARNING: mm/page_alloc.c:5197 at __alloc_frozen_pages_noprof+0x2f9/0x380 dc_create+0x38/0x660 [amdgpu] amdgpu_dm_init+0x2d9/0x510 [amdgpu] dm_hw_init+0x1b/0x90 [amdgpu] amdgpu_device_init.cold+0x150d/0x1e13 [amdgpu] amdgpu_driver_load_kms+0x19/0x80 [amdgpu] amdgpu_pci_probe+0x1e2/0x4c0 [amdgpu] dc_create() then returns NULL and DM init fails, which aborts the whole GPU init and makes amdgpu probe fail with -EINVAL (\"hw_init of IP block failed -22\"), leaving the display unusable. The subsequent amdgpu_irq_put() warnings during teardown are just fallout of unwinding a half-initialized device. struct dc is a software-only bookkeeping structure that is never handed to hardware DMA and is only ever kept as an opaque pointer, so it does not require physically contiguous memory. Allocate it with kvzalloc() (and free it with kvfree()) so that the allocator can fall back to vmalloc() when a contiguous allocation of that size is not available, which also avoids the MAX_PAGE_ORDER warning entirely. v2: - Rebase to amd-staging-drm-next. (cherry picked from commit 991e0516a8072f2292681c6ae98a924ab0e32575)", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68447", "url": "https://ubuntu.com/security/CVE-2026-68447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size from hardware without bounding it to the allocated BO region. If the HW field is larger than the queue's control stack allocation, memcpy reads past the BO into adjacent GTT memory and can leak kernel data to userspace. Store the page-aligned control stack BO size in mqd_manager and clamp checkpoint copies and reported checkpoint sizes to min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound for multi-XCC v9.4.3 checkpoint layout. (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3)", "cve_priority": "high", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68264", "url": "https://ubuntu.com/security/CVE-2026-68264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: Reset current_op in xe_pt_update_ops_init() xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it. After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind. Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry. Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(). v2 (Matt): - Add details in commit message. - Add Fixes tag and Cc to stable@vger.kernel.org (cherry picked from commit 046045543e530605c441063535e7dca0075369a6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68265", "url": "https://ubuntu.com/security/CVE-2026-68265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO's tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference (cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68267", "url": "https://ubuntu.com/security/CVE-2026-68267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists Unconditionally whitelisting OA registers is a security violation. Set RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers don't get whitelisted by default after probe, gt reset, resume and engine reset. (cherry picked from commit 90511bdcfda97211c01f1d945d4ea616578d8fca)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68273", "url": "https://ubuntu.com/security/CVE-2026-68273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68274", "url": "https://ubuntu.com/security/CVE-2026-68274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix buffer overflow in steered register list allocation The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt->fuse_topo.g_dss_mask, ...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68283", "url": "https://ubuntu.com/security/CVE-2026-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free freeing trigger private data Commit 61d445af0a7c (\"tracing: Add bulk garbage collection of freeing event_trigger_data\") moved the kfree() of event_trigger_data to a kthread that runs tracepoint_synchronize_unregister() before freeing. That removed the synchronization the trigger .free callbacks used to get implicitly and inline from trigger_data_free(). event_hist_trigger_free(), event_hist_trigger_named_free() and event_enable_trigger_free() free their satellite data (hist_data, cmd_ops, enable_data) right after trigger_data_free() returns. With the synchronization now deferred to the kthread, a concurrent tracepoint handler can still reach that data through the list_del_rcu()'d trigger, causing a use-after-free. The histogram teardown must stay synchronous: remove_hist_vars() and unregister_field_var_hists() have to detach a synthetic event from the histogram before the trigger-removal write returns, otherwise a following command races in and the synthetic-event removal fails with -EBUSY, as the trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait with the correct barrier - tracepoint_synchronize_unregister(), matching the free kthread - before freeing. The enable trigger has no such synchronous requirement, and a blocking synchronize there would re-serialize the path that commit deliberately deferred. Give it an optional private_data_free() callback that the free kthread runs after its grace period, and free enable_data from there.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68286", "url": "https://ubuntu.com/security/CVE-2026-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68287", "url": "https://ubuntu.com/security/CVE-2026-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix size calculations for 64-bit attributes net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68288", "url": "https://ubuntu.com/security/CVE-2026-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68289", "url": "https://ubuntu.com/security/CVE-2026-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68291", "url": "https://ubuntu.com/security/CVE-2026-68291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix max_vport related crash on allocation error during init Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000 [ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000 [ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20 [ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000 [ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0 [ 320.417385] PKRU: 55555554 [ 320.417398] Call Trace: [ 320.417412] [ 320.417429] pci_device_remove+0x42/0xb0 [ 320.417459] device_release_driver_internal+0x1a9/0x210 [ 320.417492] driver_detach+0x4b/0x90 [ 320.417516] bus_remove_driver+0x70/0x100 [ 320.417539] pci_unregister_driver+0x2e/0xb0 [ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0 [ 320.417592] ? kmem_cache_free+0x31e/0x550 [ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190 [ 320.417644] ? do_syscall_64+0x38/0x6b0 [ 320.417665] do_syscall_64+0xc8/0x6b0 [ 320.417683] ? clear_bhb_loop+0x30/0x80 [ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 320.417727] RIP: 0033:0x7f963bb30beb", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68303", "url": "https://ubuntu.com/security/CVE-2026-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hvs/v3d: Fix null dereference in unbind The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68312", "url": "https://ubuntu.com/security/CVE-2026-68312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and cifs_close_deferred_file_under_dentry(), when a pending deferred close is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to add the file to the local processing list may fail under memory pressure. The loop breaks immediately, but the cancelled work is no longer pending (it would have called _cifsFileInfo_put()), and the cfile is never added to file_head for processing. The cifsFileInfo reference and the open server handle both leak. Fix by saving the cfile that failed allocation in a local variable, breaking as before, and calling _cifsFileInfo_put() on it after releasing the lock. Any files later in the iteration are unaffected since their deferred work is still pending and will fire normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68316", "url": "https://ubuntu.com/security/CVE-2026-68316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Fix element size accounting for cmd stream validation There are 2 issues with the element size handling in the command stream validation which result in too small of a size calculated when the element size is 16/32/64 bits. For NHWC format, the element size is simply missing from the calculation. The bitfield for the element size is different between IFM/IFM2 and OFM. IFM and IFM2 encode the precision in parameter bits 2:3, while OFM uses bits 1:2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68440", "url": "https://ubuntu.com/security/CVE-2026-68440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix heap overflow when reading module EEPROM txgbe_read_eeprom_hostif() always copies round_up(length, 4) bytes into the caller buffer, which ethtool allocates with exactly 'length' bytes. A non-4-aligned length therefore causes an out-of-bounds write. Copy only the remaining bytes on the final dword instead.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68323", "url": "https://ubuntu.com/security/CVE-2026-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: serialize udp bearer replicast list updates tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68441", "url": "https://ubuntu.com/security/CVE-2026-68441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected. This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d (\"bpf: add bpf_redirect() helper\"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available. commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs. Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a wrapper around tcf_classify() for use by qdisc classify functions and tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT, the wrapper converts it to TC_ACT_SHOT, dropping the packet rather than letting it continue silently. Dropping is preferred over letting the packet through because the user immediately sees packet loss. Silently passing the packet through would hide the problem and leave the user wondering why their redirect is not working. The clsact fast path, tc_run() continues to call tcf_classify() directly and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by sch_handle_egress/ingress() calling skb_do_redirect() as before.", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68337", "url": "https://ubuntu.com/security/CVE-2026-68337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject redirect helpers without a bpf_net_context The bpf_redirect*() helpers and skb_do_redirect() obtain the per-task bpf_redirect_info via bpf_net_ctx_get_ri(), which dereferences the current->bpf_net_context unconditionally. That context is established on the paths that run tc BPF such as sch_handle_{ingress,egress}(), *except* for the case where {cls,act}_bpf was attached to a proper qdisc. A program running from there reaches the NULL deref in two ways: * It calls bpf_redirect() directly, which dereferences the context at the top of the helper: tc qdisc add dev eth0 root handle 1: red limit 1MB min 10KB max 20KB \\ avpkt 1000 burst 100 qevent early_drop block 10 tc filter add block 10 pref 1 bpf obj redirect.o * It simply returns TC_ACT_REDIRECT without helper call: tcf_qevent_handle() then dispatches to skb_do_redirect(), which dereferences the context Rather than extending bpf_net_context management into the qdisc path, make the redirect helpers refuse to operate when no context exists, and have tcf_qevent_handle() drop a TC_ACT_REDIRECT verdict instead of calling skb_do_redirect(). Previous behaviour was a crash, so nothing regresses by not supporting it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68345", "url": "https://ubuntu.com/security/CVE-2026-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm_mpam: guard MBWU state before adding it to garbage __destroy_component_cfg() adds each RIS mbwu_state object to the MPAM garbage list when destroying component configuration. However, mbwu_state is allocated per RIS and only for RISes with MBWU monitors. A component can therefore have comp->cfg allocated while some RISes still have ris->mbwu_state set to NULL. Passing a NULL mbwu_state to add_to_garbage() dereferences the NULL pointer inside the macro. Skip RISes that do not have an mbwu_state object before adding them to the garbage list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68347", "url": "https://ubuntu.com/security/CVE-2026-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68375", "url": "https://ubuntu.com/security/CVE-2026-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle partially initialized auxiliary devices bnxt_aux_devices_init() calls auxiliary_device_init() before all fields used by bnxt_aux_dev_release() are initialized. After auxiliary_device_init() succeeds, later errors must unwind with auxiliary_device_uninit(), which invokes the release callback. The release callback assumes that aux_priv->id, aux_priv->edev, edev->net and edev->ulp_tbl are all populated. If allocation fails after auxiliary_device_init(), the release path can otherwise dereference or clear partially initialized state. Allocate and attach the bnxt_en_dev and ULP table before calling auxiliary_device_init(), so the release callback only sees a fully initialized auxiliary private object. If auxiliary_device_init() itself fails, free those allocations directly because device_initialize() has not run and the release callback will not be invoked. 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-68382", "url": "https://ubuntu.com/security/CVE-2026-68382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Hold device ref until queue teardown completes GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock. Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending. Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work. With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. Replace the fini wait with an assertion and remove the unused fini_wq. v2: - Rebase v3: - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt) - Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt) - Drop separate deferred drm_dev_put worker. - Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini(). v4: - Replace the guc_submit_sw_fini() wait with an assertion and remove the now-unused fini_wq. (sashiko) v5: - Move destroy work to a module-lifetime Xe workqueue instead of system_dfl_wq. (Matt) - Flush the module-lifetime destroy workqueue during PCI remove to preserve the old device-remove wait semantics. v6: - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid letting it outlive the xe_device/drm_device. (Sashiko) - Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work can be queued from the reclaim path. v7: - Drop the per-device xe->destroy_wq and use the module-level destroy WQ for SVM pagemap destroy as well. (Matt) - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*() helpers because the WQ is no longer exec-queue specific. (Matt) v8: - Rebase. v9: - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM destroy_wq because it can be queued from reclaim and embeds the dev_pagemap used by devres teardown. (Sashiko) - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM from it. - Update the module-WQ kdoc to document the GuC/SVM split. v10: - Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the workqueue allocation warning. v11: - Drop the SVM pagemap destroy comment as it was revision-specific. (Thomas) v12: - Rebase. (cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68383", "url": "https://ubuntu.com/security/CVE-2026-68383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Keep scheduler timeline name alive The scheduler keeps a pointer to the timeline name, but q->name is freed with the exec queue while scheduler fences can still reference it. Store the name in struct xe_guc_exec_queue so it shares the scheduler's RCU-deferred lifetime. (cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68390", "url": "https://ubuntu.com/security/CVE-2026-68390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups hci_conn_params_lookup requires hdev->lock be held, otherwise the list iteration or param access is not safe. Hold hdev->lock for params lookups in hci_sync.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-2026-68404", "url": "https://ubuntu.com/security/CVE-2026-68404", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: use wiphy work for socket owner autodisconnect nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68367", "url": "https://ubuntu.com/security/CVE-2026-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: synchronize delayed set_alt with teardown The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68095", "url": "https://ubuntu.com/security/CVE-2026-68095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse-uring: fix race between registration and connection abortion This fixes this race: - thread a: io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref yet - thread b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() is a no-op due to queue ref being 0 - thread a: grabs the queue_ref, queue_ref is now 1, rest of fuse_uring_do_register() logic executes - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs and calls \"wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);\" The abort/unmount thread will hang indefinitely in unkillable state as nothing will decrement queue_refs or wake stop_waitq, and the ring, queue, and ent are leaked. Fix this by checking fch->connected under fch->lock after the created ent has grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either release the queue ref and wake up stop_waitq (in case fuse_chan_wait_aborted() is already waiting) in fuse_uring_do_register() when we detect !fch->connected, or if the connection is aborted after the check, it is guaranteed that the async teardown worker will be running in the background cleaning up ents and decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-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-68173", "url": "https://ubuntu.com/security/CVE-2026-68173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: wait on ublk_dev_ready() instead of ub->completion ub->completion is only re-armed by a successful START_USER_RECOVERY. If the ublk server sends END_USER_RECOVERY without one - e.g. its START failed with -EBUSY and the error was ignored - the wait is satisfied by the stale completion of the previous recovery cycle, and the device is marked LIVE and the requeue list kicked while the FETCH stream is still running and ubq->canceling is still set. The kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it again via __ublk_abort_rq(), and after the last FETCH clears ->canceling nothing ever kicks the requeue list again: the request is stranded there while holding its tag. If it is the flush machinery's flush_rq, every subsequent fsync piles up in uninterruptible sleep and teardown hangs on tag draining. This matches a report of a lost PREFLUSH with ext4 on top of ublk after daemon crash recovery. ub->completion is an edge-triggered latch used as a proxy for the level condition \"every queue has fetched all I/O commands\", which can regress (F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop it and wait on the real condition instead: the new helper ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then re-checks it under ub->mutex, waiting again on regression, and returns with the mutex held and readiness guaranteed. Readiness becomes true in the same ub->mutex critical section that clears the last queue's ->canceling, so END_USER_RECOVERY marks the device LIVE and kicks the requeue list strictly after ->canceling clears. The wait stays interruptible, so a server whose daemon died can still be signalled out. For ublk_ctrl_start_dev() this replaces the fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting until the device is ready again.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68113", "url": "https://ubuntu.com/security/CVE-2026-68113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68118", "url": "https://ubuntu.com/security/CVE-2026-68118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: challenge ACK for non-exact RST in SYN-RECEIVED The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68120", "url": "https://ubuntu.com/security/CVE-2026-68120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtase: Workaround for TX hang caused by hardware packet parsing The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission.", "cve_priority": "medium", "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-68122", "url": "https://ubuntu.com/security/CVE-2026-68122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix peer refcount leak in TCP error paths When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&peer->tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object. The race window: CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error): ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2 schedule_work() <- queued schedule_work() <- NO-OP (work already pending) ovpn_tcp_peer_del_work runs: ovpn_peer_del() ovpn_peer_put() <- refcnt+1 <- peer never freed Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68128", "url": "https://ubuntu.com/security/CVE-2026-68128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: reject out-of-range ptype in ice_parser_profile_init set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from providing ptype >= 1024 through VIRTCHNL, resulting in a write past the end of the bitmap and a kernel page fault. Reproduced with a custom kernel module injecting a crafted VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1. crash_parser: ice_parser_profile_init @ ffffffffc0d61b60 crash_parser: setting ptype=0xffff (max valid=1023) crash_parser: calling ice_parser_profile_init -- expect OOB crash! BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace: ? __pfx_ice_parser_profile_init+0x10/0x10 [ice] crash_init+0x127/0xff0 [crash_parser] do_one_initcall+0x45/0x310 do_init_module+0x64/0x270 init_module_from_file+0xcc/0xf0 idempotent_init_module+0x17b/0x280 __x64_sys_finit_module+0x6e/0xe0 Bail out early with -EINVAL when ptype is out of range.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68132", "url": "https://ubuntu.com/security/CVE-2026-68132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: super: fix emergency thaw deadlock on frozen block devices do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68133", "url": "https://ubuntu.com/security/CVE-2026-68133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP Call Trace during PTP release If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will result in the following PTP release call trace during driver unload: kernel BUG at lib/list_debug.c:52! ice_ptp_release+0x332/0x3c0 [ice] ice_deinit_features.part.0+0x10e/0x120 [ice] ice_remove+0x100/0x220 [ice] This was observed when passing PF1 through to a VM. ice_ptp_init() fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT. Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and returning without error, preventing the invalid state transition to ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from ICE_PTP_RESETTING after a failed rebuild.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68134", "url": "https://ubuntu.com/security/CVE-2026-68134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: ptp_s390: Add missing facility check Only register the physical clock when facility 28 is installed and PTFF QAF returns that PTFF QPT is available.", "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-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-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-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-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-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-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-68150", "url": "https://ubuntu.com/security/CVE-2026-68150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/super: fix emergency thaw double-unlock of s_umount do_thaw_all() iterates over all superblocks via __iterate_supers() with SUPER_ITER_EXCL, which acquires s_umount exclusively before calling the callback and releases it afterwards. However, the callback do_thaw_all_callback() calls thaw_super_locked() which unconditionally releases s_umount on every code path. This results in a second unlock attempt in __iterate_supers() that corrupts the rwsem state, triggering a DEBUG_RWSEMS warning: [ 182.601148] sysrq: Emergency Thaw of all frozen filesystems [ 182.601865] ------------[ cut here ]------------ [ 182.602375] DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff99b1011e5870, owner = 0x0, curr 0xffff99b101b06c80, list not empty [ 182.603817] WARNING: kernel/locking/rwsem.c:1412 at up_write+0xa3/0x170, CPU#2: kworker/2:1/53 [ 182.604578] Modules linked in: [ 182.604864] CPU: 2 UID: 0 PID: 53 Comm: kworker/2:1 Not tainted 7.2.0-rc4-00001-gbd3bd93ea98a-dirty #4 PREEMPT(lazy) [ 182.605711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014 [ 182.606417] Workqueue: events do_thaw_all [ 182.606750] RIP: 0010:up_write+0xaf/0x170 [ 182.607076] Code: 19 3a 92 48 0f 44 c2 48 8b 55 08 48 8b 55 00 4c 8b 45 08 48 8b 55 00 48 8d 3d ad 91 e0 01 48 8b 4d 20 50 48 c7 c6 f0 8c 26 92 <67> 48 0f b9 3a e8 d7 93 4e 00 58 eb 81 48 83 7f 18 00 48 c7 c2 8d [ 182.608563] RSP: 0018:ffffb670001d7e08 EFLAGS: 00010246 [ 182.609007] RAX: ffffffff92349e8d RBX: 0000000000000000 RCX: ffff99b1011e5870 [ 182.609595] RDX: 0000000000000000 RSI: ffffffff92268cf0 RDI: ffffffff92914d10 [ 182.610283] RBP: ffff99b1011e5870 R08: 0000000000000000 R09: ffff99b101b06c80 [ 182.610847] R10: ffff99b10139a808 R11: fefefefefefefeff R12: 0000000000000000 [ 182.611414] R13: ffffffff90cf74d0 R14: 0000000000000000 R15: ffff99b1011e5800 [ 182.612009] FS: 0000000000000000(0000) GS:ffff99b1eaaee000(0000) knlGS:0000000000000000 [ 182.612670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 182.613146] CR2: 00000000005c631c CR3: 00000000013ee000 CR4: 00000000000006f0 [ 182.613722] Call Trace: [ 182.613946] [ 182.614130] __iterate_supers+0x128/0x150 [ 182.614463] do_thaw_all+0x1b/0x30 [ 182.614759] process_scheduled_works+0xbb/0x3f0 [ 182.615150] ? __pfx_worker_thread+0x10/0x10 [ 182.615499] worker_thread+0x129/0x270 [ 182.615816] ? __pfx_worker_thread+0x10/0x10 [ 182.616201] kthread+0xe2/0x120 [ 182.616469] ? __pfx_kthread+0x10/0x10 [ 182.616792] ret_from_fork+0x15b/0x240 [ 182.617115] ? __pfx_kthread+0x10/0x10 [ 182.617426] ret_from_fork_asm+0x1a/0x30 [ 182.617761] [ 182.617968] ---[ end trace 0000000000000000 ]--- [ 182.618412] Emergency Thaw complete Fix this by switching to SUPER_ITER_UNLOCKED and acquiring s_umount in the callback via super_lock_excl() before calling thaw_super_locked(). This matches the locking pattern expected by thaw_super_locked() and eliminates the double unlock. While at it, remove the dead 'return;' at the end of do_thaw_all_callback().", "cve_priority": "low", "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-68152", "url": "https://ubuntu.com/security/CVE-2026-68152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: fix use-after-free in AMT delayed works When an AMT device is removed, pending delayed works can still access the freed amt_dev structure, which may result in kernel crashes or memory corruption. amt_dev_stop() cancels req_wq and discovery_wq with cancel_delayed_work_sync(), but these works can be scheduled again from event_wq after the cancellation. This allows delayed works to access the freed amt_dev structure after the netdev has been released. The following is a simple race scenario: CPU0 CPU1 amt_dev_stop() cancel_delayed_work_sync() amt_event_work() mod_delayed_work(req_wq) free netdev req_wq accesses freed amt_dev Use disable_delayed_work_sync() in amt_dev_stop() to prevent req_wq and discovery_wq from being queued again and wait for running work items to complete. The delayed works are disabled after initialization in amt_newlink() and enabled only when the device is successfully opened. This keeps the delayed work lifecycle synchronized with the lifetime of the AMT device.", "cve_priority": "high", "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-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-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-68168", "url": "https://ubuntu.com/security/CVE-2026-68168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix afs_edit_dir_remove() to get, not find, block 0 Fix afs_edit_dir_remove() to use afs_dir_get_block() to get block 0 rather than afs_dir_find_block() as the latter caches the found block in the afs_dir_iter and may[*] switch out the page it's on if another afs_dir_find_block() is done. This parallels what afs_edit_dir_add() does. [*] There's more than one block per page.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68169", "url": "https://ubuntu.com/security/CVE-2026-68169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: userspace: fix use-after-free in get_local_id In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a \"not found\" sentinel.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68172", "url": "https://ubuntu.com/security/CVE-2026-68172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: make huge_ptep_get handled unaligned addresses huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma). The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned. On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map or into a hole, dereference a VA not mapped into the kernel pgtables and cause kernel panic. Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68174", "url": "https://ubuntu.com/security/CVE-2026-68174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix union collision of module and refcnt for dynamic events In 'struct trace_event_call', the 'module' pointer and the 'refcnt' atomic variable share the same memory space in a union. For dynamic events, the union member is 'refcnt', which acts as an active reference counter. When a dynamic event (such as kprobe, uprobe, fprobe, eprobe, or wprobe) has a non-zero reference count (e.g. due to active event triggers or perf attachments), its 'call->module' evaluates to a small non-zero integer instead of NULL. When filtering or setting events for a specific module (e.g., writing ':mod:' to 'set_event'), the code in '__ftrace_set_clr_event_nolock()' and 'update_event_fields()' reads 'call->module' directly without checking whether the event is dynamic. This causes the kernel to treat the small integer (refcnt) as a 'struct module' pointer, leading to a NULL/invalid pointer dereference (Oops) when dereferencing the module name. Fix this by ensuring that the 'TRACE_EVENT_FL_DYNAMIC' flag is checked before treating 'call->module' as a valid pointer in these code paths.", "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-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-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-68434", "url": "https://ubuntu.com/security/CVE-2026-68434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms Commit b1b4efea05a5 (\"serial: 8250_mid: Disable DMA for selected platforms\") replaced the dnv_board setup and exit callbacks with PTR_IF(false, ...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. Fix this by adding the missing NULL checks before calling the setup and exit callbacks.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17: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-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-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16: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-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-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-68198", "url": "https://ubuntu.com/security/CVE-2026-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix use-after-free in aggr_reset_state() The aggr_reset_state() function uses timer_delete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggr_module_destroy(). If the timer callback (aggr_timeout) is executing when aggr_reset_state() is called, the callback will continue to access aggr_conn fields like rx_tid[] and stat[] which may be freed immediately after by kfree(aggr_info->aggr_conn) in aggr_module_destroy(). Additionally, the timer callback can re-arm itself via mod_timer() while aggr_reset_state() is running, creating a more complex race condition. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "high", "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-68200", "url": "https://ubuntu.com/security/CVE-2026-68200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: don't re-enter an instance callback that is still running The userspace-driven timer (utimer) TRIGGER ioctl calls snd_timer_interrupt() directly with no serialization, so two threads triggering the same utimer can run snd_timer_interrupt() on one snd_timer concurrently. snd_timer_process_callbacks() drops timer->lock around each instance callback and marks the in-flight callback with the single SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that bit to drain an in-flight callback before freeing the instance. The bit cannot represent two concurrent callbacks: when a second interrupt re-queues an instance whose callback is still running, both run at once, the first to finish clears the bit, and the close-path drain then frees the instance (and its callback_data) while the other callback is still live - a use-after-free reachable by any user able to open /dev/snd/timer, both via a user timer instance and via a sequencer queue timer bound to the utimer. snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so a concurrent interrupt already observes it under the lock. Skip re-queuing an instance (and its slaves) to the ack/sack list while its callback is in flight; the accumulated pticks are delivered on the next tick, so no event is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68201", "url": "https://ubuntu.com/security/CVE-2026-68201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: drain a slave's callback before its master detaches it snd_timer_close_locked() drains the closing instance's own in-flight callback (IFLG_CALLBACK) before freeing it, but not its slaves'. When a master instance is closed, remove_slave_links() clears each slave's ->timer; the slave's own close then reads timer == NULL and takes the branch that skips the drain entirely (snd_timer_stop_slave() also no-ops on a NULL timer). So a slave whose callback is still running when the master is closed is freed underneath the live callback, leading to use-after-free. Drain the slaves too before remove_slave_links() severs them. snd_timer_stop() has already taken this instance off the active list, so no new slave callback can be queued. Take the slaves off the ack list so a pending one can't fire either, then wait for any that is already in flight.", "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-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-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-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-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-68211", "url": "https://ubuntu.com/security/CVE-2026-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32-dcmipp: 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. dcmipp_bytecap_start_streaming() returned -EINVAL when the source subdevice could not be resolved from the media graph, before pm_runtime_resume_and_get() and media_pipeline_start() had been called. The remaining error paths already converge on the err_buffer_done label, which calls dcmipp_bytecap_all_buffers_done(..., VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate err_pm_put / err_media_pipeline_stop 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": "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-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-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-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-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-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-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-68230", "url": "https://ubuntu.com/security/CVE-2026-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: amlogic-c3: Add validations for ae and awb config Avoid invalid memory access if the zones_num is bigger than zone_weight. This patch fixes the following smatch errors: drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max", "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-68232", "url": "https://ubuntu.com/security/CVE-2026-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path.", "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-68233", "url": "https://ubuntu.com/security/CVE-2026-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Shut down BO cache timer before teardown The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20: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-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-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-68238", "url": "https://ubuntu.com/security/CVE-2026-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Release VFCT ACPI table reference amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68239", "url": "https://ubuntu.com/security/CVE-2026-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Account for NULL and handle pages in ttm_pool_backup Pages in ttm_pool_backup can be NULL or backup handles (ttm_backup_page_ptr_is_handle()), neither of which can be passed to set_pages_array_wb() or freed. Add a dedicated WB pass before the dma/purge loop that walks allocations using the same i += num_pages stride, skipping NULL and handle entries, and calls set_pages_array_wb() once per contiguous run of real pages. Apply the same NULL/handle guard to the dma/purge loop. Fixes the following oops: Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI RIP: 0010:__cpa_process_fault+0xf8/0x770 RSP: 0018:ffffc90000a87718 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34 RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0 R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000 R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0 FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0 PKRU: 55555554 Call Trace: __change_page_attr_set_clr+0x989/0xe90 ? __purge_vmap_area_lazy+0x6c/0x3a0 ? _vm_unmap_aliases+0x250/0x2a0 set_pages_array_wb+0x7f/0x120 ttm_pool_backup+0x4c9/0x5b0 [ttm] ? dma_resv_wait_timeout+0x3b/0xf0 ttm_tt_backup+0x32/0x60 [ttm] ttm_bo_shrink+0x66/0x110 [ttm] xe_bo_shrink_purge+0x12b/0x1b0 [xe] xe_bo_shrink+0xbb/0x270 [xe] __xe_shrinker_walk+0xf7/0x160 [xe] xe_shrinker_walk+0x9d/0xc0 [xe] xe_shrinker_scan+0x11f/0x210 [xe] do_shrink_slab+0x13b/0x270 shrink_slab+0xf1/0x400 shrink_node+0x352/0x8a0 balance_pgdat+0x32c/0x700 kswapd+0x205/0x2f0 ? __pfx_autoremove_wake_function+0x10/0x10 ? __pfx_kswapd+0x10/0x10 kthread+0xd1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1b1/0x200 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68241", "url": "https://ubuntu.com/security/CVE-2026-68241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/mst: limit DP MST ESI service loop The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto. (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)", "cve_priority": "medium", "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-68245", "url": "https://ubuntu.com/security/CVE-2026-68245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only valid while the lock is still being held. Once xa_unlock_irqrestore is called and returned, the pointer is no longer under lock and is subject to modification. Since, the caller still dereferences vm->task_info in amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a use after unlock problem. Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid() through removing the amdgpu_vm_get_vm_from_pasid() function from amdgpu_vm.c and making the relevant code inline to hold the lock while it is still in use. (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)", "cve_priority": "high", "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-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-68252", "url": "https://ubuntu.com/security/CVE-2026-68252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68253", "url": "https://ubuntu.com/security/CVE-2026-68253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)", "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-68257", "url": "https://ubuntu.com/security/CVE-2026-68257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix 32-bit overflow in CWSR total size calculation total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68258", "url": "https://ubuntu.com/security/CVE-2026-68258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on CRIU restore queue type and mqd size We weren't checking whether the values provided in the private data in kfd CRIU restore were within bounds. For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it. For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations. (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)", "cve_priority": "low", "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-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-68266", "url": "https://ubuntu.com/security/CVE-2026-68266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68268", "url": "https://ubuntu.com/security/CVE-2026-68268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Return error on non-migratable faults requiring devmem Non-migratable faults that require devmem incorrectly jump to the 'out' label, which squashes the error code intended to be returned to the upper layers. Fix this by returning -EACCES instead. (cherry picked from commit c4508edb2c723de93717272488ea65b165637eac)", "cve_priority": "medium", "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-68270", "url": "https://ubuntu.com/security/CVE-2026-68270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Avoid possible truncation with calculating visible size Calculating the visible size of the system framebuffer can result in truncation of the result. The calculation uses 32-bit arithmetics, which can overflow if the values for height and stride are large. Fix the issue by multiplying with mul_u32_u32().", "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-68275", "url": "https://ubuntu.com/security/CVE-2026-68275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks up the bo_va for the buffer object in the caller's VM via amdgpu_vm_bo_find(), but uses the returned pointer without checking it. amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM, which is the normal case for a BO that has never been mapped. The result is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which expands to list_for_each_entry(mapping, &(bo_va)->valids, list) and dereferences bo_va, causing a NULL pointer dereference. This is reachable by any process able to issue the ioctl (render group) simply by requesting mapping info for an unmapped BO. Return -ENOENT when no bo_va is found, jumping to out_exec so the drm_exec context and GEM object reference are released. (cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68276", "url": "https://ubuntu.com/security/CVE-2026-68276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx: fix cleaner shader IB buffer overflow The cleaner shader sysfs path allocates a 16-dword (64 byte) IB but incorrectly fills (align_mask + 1) dwords. On GFX rings align_mask is 0xff, so the loop wrote 256 dwords into a 64-byte buffer, causing a kernel page fault. The IB only needs to be a minimal NOP shell to schedule the job; the cleaner shader itself is emitted on the ring via emit_cleaner_shader(). Fill 16 dwords to match the allocation. v2: Use ib_size_dw variable (Lijo) (cherry picked from commit bf21af331ebf72d0935fd70c73192414a422c03a)", "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-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-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-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-68282", "url": "https://ubuntu.com/security/CVE-2026-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: analogix_dp: Add missing error check for platform_get_resource() Add missing error check for platform_get_resource() return value to prevent NULL pointer dereference when memory resource is not available.", "cve_priority": "medium", "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-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-68292", "url": "https://ubuntu.com/security/CVE-2026-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues.", "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-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-68296", "url": "https://ubuntu.com/security/CVE-2026-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM Before commit 00d066a4d4ed (\"netdev_features: convert NETIF_F_LLTX to dev->lltx\"), NETIF_F_LLTX was set unconditionally in both __gre_tunnel_init() and ip6gre_tnl_init_features() alongside GRE_FEATURES: dev->features |= GRE_FEATURES | NETIF_F_LLTX; When that commit converted NETIF_F_LLTX to the dev->lltx flag, it placed 'dev->lltx = true' after the SEQ/CSUM early returns instead of before them. This causes GRE/GRETAP/ip6gre tunnels with SEQ or CSUM+encap to lose lockless TX, reintroducing _xmit_lock acquisition around their ndo_start_xmit. Since GRE xmit re-enters the stack via ip_tunnel_xmit(), holding _xmit_lock risks ABBA deadlock with the underlay device. CPU0 CPU1 ---- ---- lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); Fix by moving dev->lltx = true before the early returns in both functions, restoring the original unconditional behavior.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64575", "url": "https://ubuntu.com/security/CVE-2026-64575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: fix double sock release on batch realloc bpf_iter_tcp_batch() releases the current batch via bpf_iter_tcp_put_batch(), which drops the socket refs and rewrites each slot with the socket cookie, then grows the batch. cur_sk/end_sk are kept for bpf_iter_tcp_resume(), but on realloc failure the function returns ERR_PTR() before resume runs, leaving cur_sk < end_sk over slots that now hold cookies rather than sock pointers. bpf_iter_tcp_seq_stop() then calls bpf_iter_tcp_put_batch() again and dereferences a cookie as a struct sock. Empty the batch on the failure path so stop() does not release it again. The sockets were already freed by the first bpf_iter_tcp_put_batch(), so nothing leaks, and a later read() rescans the bucket from the start instead of skipping it. The sibling GFP_NOWAIT failure path still holds real socket references and is left for stop() to release. BUG: KASAN: null-ptr-deref in __sock_gen_cookie Read of size 8 at addr 0000000000000059 by task exploit ... __sock_gen_cookie (net/core/sock_diag.c:28) bpf_iter_tcp_put_batch (net/ipv4/tcp_ipv4.c:2918) bpf_iter_tcp_seq_stop (net/ipv4/tcp_ipv4.c:3270) bpf_seq_read (kernel/bpf/bpf_iter.c:205) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 entry_SYSCALL_64_after_hwframe Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68298", "url": "https://ubuntu.com/security/CVE-2026-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create() Commit 9e9787414882 (\"drm/xe/userptr: replace xe_hmm with gpusvm\") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a \"simple\" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). (cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4)", "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-68448", "url": "https://ubuntu.com/security/CVE-2026-68448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: check access to copy_file_range source with src mounter creds Commit 5dae222a5ff0c (\"vfs: allow copy_file_range to copy across devices\") allowed filesystems that implement the copy_file_range() f_op to decide if they want to access cross-sb copy from/to the same fs type. The same commit added checks to verify same sb copy for filesystems that implement ->copy_file_range() and do not support cross-sb copy at the time, namely, to ceph, fuse and nfs. The two remaining fs which implement ->copy_file_range(), cifs and overlayfs started to support cross-sb copy from this time. While overlayfs does support cross-sb copy when the two underlying files are on the same base fs, the copy operation on the two real files from two different overalyfs filesystems is performed with the mounter creds of the destination overlayfs and the read permission access hook for the source file was called with the wrong creds. This could cause either deny of access to copy which would otherwise be allowed (e.g. with splice) or allow read access to file which would otherwise be denied. Fix the latter case by explicitly verifying read access to source file with the source overlayfs mounter creds. The former case remains a quirk of cross-sb overlayfs copy, but userspace could fall back to regular copy so no harm done.", "cve_priority": "low", "cve_public_date": "2026-08-12 01:17: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-68307", "url": "https://ubuntu.com/security/CVE-2026-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix crash in reset link replay During reset recovery, mt7925_vif_connect_iter() replays firmware state for links tracked in mvif->valid_links. After MLO link changes or MCU timeout recovery, the driver bitmap can temporarily contain a link whose mac80211 bss_conf has already gone away. This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching the crash where x1, the second argument, is NULL: pc : mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] lr : mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] x2 : ffffff80a77f6018 x1 : 0000000000000000 x0 : ffffff8099402080 Call trace: mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common] Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA reset replay is unchanged because the helper still returns &vif->bss_conf for the legacy link.", "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-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-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-68311", "url": "https://ubuntu.com/security/CVE-2026-68311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: guard link STA in decap offload mt7925_sta_set_decap_offload() iterates over the vif valid_links mask when updating decap offload state for an MLO station. The station may not have a link STA for every valid link of the vif, so mt792x_sta_to_link() can return NULL for a link that belongs to the vif but not to the station. The function currently dereferences mlink before checking whether the link WCID is ready. If mlink is NULL, setting or clearing MT_WCID_FLAG_HDR_TRANS dereferences a NULL pointer. Skip links without a station link before touching mlink->wcid.", "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-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-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-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-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-68321", "url": "https://ubuntu.com/security/CVE-2026-68321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix FDIR filter leak on remove Perfect FDIR filters can be added while the interface is down and are kept on the software list for later restore. unregister_netdev() only calls ndo_stop when the device is up, so txgbe_fdir_filter_exit() in txgbe_close() is skipped in that case and the filters are leaked on driver remove. Free the filter list from txgbe_remove() as well.", "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-68330", "url": "https://ubuntu.com/security/CVE-2026-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix DMA direction for NPU mailbox buffer airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE, but some callers expect the NPU to write response data back into the same buffer: - airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into the buffer, then the caller reads it via memcpy() - airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back npu_stats_addr field in the response On non-cache-coherent architectures like EN7581 (Cortex-A53 without hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op — it does not invalidate the CPU cache. If the NPU-written cache line is still present in the CPU cache when the caller reads the buffer, the CPU observes stale data instead of the NPU response. This is a timing-sensitive bug: small mailbox buffers (~24 bytes) typically fit in a single cache line and may survive in the cache until the caller reads them, producing silent data corruption rather than a crash. The bug is more likely to trigger when the caller reads the response immediately after dma_unmap_single() without intervening cache-evicting operations. Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures dma_unmap_single() invalidates the CPU cache on non-coherent systems. The mailbox buffers are small so there is no performance concern.", "cve_priority": "low", "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-68332", "url": "https://ubuntu.com/security/CVE-2026-68332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix potential use-after-free in airoha_ppe_deinit() airoha_ppe_deinit() replaces the NPU pointer with NULL via rcu_replace_pointer() but does not wait for existing RCU readers to exit before calling ppe_deinit() and airoha_npu_put(). This can cause a use-after-free if a reader in an RCU read-side critical section still holds a reference to the NPU when it is freed. The init path (airoha_ppe_init) already calls synchronize_rcu() after rcu_assign_pointer(), but the deinit path introduced in commit 6abcf751bc08 (\"net: airoha: Fix schedule while atomic in airoha_ppe_deinit()\") omitted the matching barrier when switching from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer(). Add synchronize_rcu() before ppe_deinit() to ensure all existing RCU readers have completed before the NPU resources are released.", "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-68334", "url": "https://ubuntu.com/security/CVE-2026-68334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix io_thread race in rxrpc_wake_up_io_thread() rxrpc_wake_up_io_thread() checks local->io_thread before waking it, but then reloads the pointer for wake_up_process(). local->io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so the second load can see NULL even if the first load did not. Take a READ_ONCE() snapshot and use it for both the NULL check and the wake_up_process() call, as rxrpc_encap_rcv() already does.", "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-68341", "url": "https://ubuntu.com/security/CVE-2026-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix use after free in unlock_ovpn() unlock_ovpn() iterates over the release_list using llist_for_each_entry() and drops the peer reference inside the loop body via ovpn_peer_put(). If this drops the last reference, the peer is eventually freed. However, llist_for_each_entry() reads peer->release_entry.next in the loop advance expression, which runs after the body. By that time the peer may have already been freed, resulting in a use after free when advancing to the next list entry. Fix this by using llist_for_each_entry_safe(), which caches the next pointer before executing the loop body.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68342", "url": "https://ubuntu.com/security/CVE-2026-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: avoid putting unrelated P2P peer on socket release ovpn_peer_release_p2p() is called when an OVPN UDP socket is being destroyed. It checks the currently published P2P peer and releases it only if that peer still uses the socket being destroyed. A peer replacement can publish a new peer before the old UDP socket is destroyed. When the old socket destruction path runs afterwards, ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the new peer uses a different socket, the function takes the socket mismatch branch. That branch still calls ovpn_peer_put(peer). At this point, however, peer is the currently published replacement peer, not the peer associated with the socket being destroyed. Dropping its reference can free it while ovpn->peer still points to it, leading to later use-after-free accesses from the peer and socket cleanup paths. KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer object. In the reproducer, the object is allocated from ovpn_peer_new() via ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU callback processing. Observed access sites include ovpn_peer_remove(), ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn(). Fix this by returning from the socket mismatch branch without putting the peer.", "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-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-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-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-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-68356", "url": "https://ubuntu.com/security/CVE-2026-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: airoha: Prevent division by zero when clock frequency is zero clk_get_rate() can return 0 when the clock provider is not properly configured or the clock is unmanaged. The driver uses wdt_freq as a divisor directly in airoha_wdt_probe() to compute max_timeout and in airoha_wdt_get_timeleft() to compute the remaining time, which results in a division by zero. Add a check for wdt_freq == 0 in probe and return -EINVAL with dev_err_probe() to prevent the division by zero and provide a diagnostic message.", "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-68358", "url": "https://ubuntu.com/security/CVE-2026-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-kraken3) 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-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-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-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-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-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-68374", "url": "https://ubuntu.com/security/CVE-2026-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: sysfs: add lock to bos_descriptors_read() Add a lock to the function bos_descriptors_read(). This function accesses udev->bos, which could be simultaneously freed in usb_reset_and_verify_device(), a function that is commonly called in drivers all over the kernel.", "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-68378", "url": "https://ubuntu.com/security/CVE-2026-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions: - A pin is registered with two or more dpll devices (dpll_A, dpll_B) - The pin has ref_sync pairs with other pins - During unregistration of dpll_A's pins, a ref_sync partner pin is unregistered first, removing it from dpll_A->pin_refs - But since the partner pin is still registered with dpll_B, its dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT run and the partner stays in the pin's ref_sync_pins xarray - When the pin itself is then unregistered from dpll_A, the delete notification calls dpll_msg_add_pin_ref_sync() which finds the partner in ref_sync_pins, passes dpll_pin_available() (partner is still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A, partner) returns NULL because partner was already removed from dpll_A->pin_refs - The NULL priv pointer is passed to the driver's ref_sync_get callback, which dereferences it BUG: kernel NULL pointer dereference, address: 0000000000000034 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x] Call Trace: dpll_msg_add_pin_ref_sync+0xb8/0x200 dpll_cmd_pin_get_one+0x3b6/0x4b0 dpll_pin_event_send+0x72/0x140 __dpll_pin_unregister+0x5a/0x2b0 dpll_pin_unregister+0x49/0x70 Fix this by skipping ref_sync pins whose priv pointer cannot be resolved for the current dpll device.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68379", "url": "https://ubuntu.com/security/CVE-2026-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix TIME_WAIT socket reference leak on PSP policy failure Release the TIME_WAIT socket reference and jump to discard_it upon PSP policy failure in both IPv4 and IPv6 receive paths. This prevents a memory leak of tcp_tw_bucket structures.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68380", "url": "https://ubuntu.com/security/CVE-2026-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix use-after-free of mm_struct in job scheduler amdxdna_cmd_submit() stores current->mm in job->mm without holding any reference. aie2_sched_job_run() later access job->mm from the DRM scheduler worker thread. With only a raw pointer and no structural reference, the mm_struct can be freed before the scheduler runs the job. Fix this by calling mmgrab() to hold a structural mm_count reference for the lifetime of the job, paired with mmdrop() in every cleanup path.", "cve_priority": "high", "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-68384", "url": "https://ubuntu.com/security/CVE-2026-68384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits. - Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it. While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one. (cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68385", "url": "https://ubuntu.com/security/CVE-2026-68385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/checksum: Fix csum_partial() without vector facility Currently csum_partial() calls csum_copy() with copy=false and dst=NULL. On machines without the vector facility, csum_copy() falls back to cksm(dst, ...), causing the checksum to be calculated from address zero instead of the source buffer. The VX implementation already checksums data loaded from src. Make the fallback do the same by passing src to cksm().", "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-68387", "url": "https://ubuntu.com/security/CVE-2026-68387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: add locking for raw flags bitfield With commit 890e5198a6e5 (\"can: raw: use bitfields to store flags in struct raw_sock\") the formerly separate integer values have been integrated into a single bitfield. This led to a read-modify-write operation when changing a flag in raw_setsockopt() which now needs a locking to prevent concurrent access. Instead of adding a lock/unlock hell in each of the flag manipulations this patch introduces a wrapper for a new raw_setsockopt_locked() function analogue to the isotp_setsockopt[_locked]() approach in net/can/isotp.c [mkl: use Closes tag instead of Link]", "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-68393", "url": "https://ubuntu.com/security/CVE-2026-68393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: extend conn_hash lookup critical sections Using RCU-protected pointers outside the critical sections without refcount is incorrect and may result to UAF. Extend critical section to cover both hci_conn_hash lookup and use of the returned conn. Add surrounding rcu_read_lock() also when return value is not used, in preparation for RCU lockdep requirement to hci_lookup_le_connect(). This avoids concurrent deletion of the conn before we are done dereferencing it. Also, make sure to hold hdev->lock when accessing hdev->accept_list.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68394", "url": "https://ubuntu.com/security/CVE-2026-68394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update MGMT_OP_LOAD_CONN_PARAM queues conn_update_sync() when a single parameter update changes an existing LE central connection. The queued work currently stores a borrowed hci_conn_params entry from hdev->le_conn_params. A later LOAD_CONN_PARAM request can clear disabled parameters and free that entry before hci_cmd_sync_work() runs the queued callback. Do not keep the borrowed hci_conn_params pointer in queued work. Queue the hci_conn instead and hold a reference until the queued callback completes. When the work runs, revalidate that the connection is still present, look up the current hci_conn_params entry, and cancel the update if userspace removed that entry while the work was pending. Copy the interval values from the current params entry under hdev->lock, then drop the lock and keep using hci_le_conn_update_sync() to issue the update. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in conn_update_sync+0x2a/0xf0 [bluetooth] Read of size 1 at addr ffff88810c697126 by task kworker/u17:0/377 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 kasan_report+0xe0/0x110 conn_update_sync+0x2a/0xf0 [bluetooth] hci_cmd_sync_work+0x187/0x210 [bluetooth] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 Allocated by task 466: hci_conn_params_add+0xa6/0x240 [bluetooth] load_conn_param+0x4e1/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] Freed by task 474: kfree+0x313/0x590 hci_conn_params_clear_disabled+0x9b/0xc0 [bluetooth] load_conn_param+0x4bf/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth]", "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-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-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-68400", "url": "https://ubuntu.com/security/CVE-2026-68400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint memory access array and to comply with the FF-A spec instead of defaulting to `sizeof(struct ffa_mem_region)`. This requires moving `ffa_mem_region_additional_setup()` earlier in the setup flow. Also, add sanity checks to ensure the calculated descriptor offsets do not exceed `max_fragsize`.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68401", "url": "https://ubuntu.com/security/CVE-2026-68401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() Sashiko (locally) reports multiple out-of-bound issues in ffa_setup_and_transmit: 1) Writing ep_mem_access->reserved can write out of bounds for FFA versions < 1.2 as ffa_emad_size_get() returns 16 bytes in that case while reserved has an offset of 24. Instead of zeroing fields, memset the struct to zero first based on the FFA version. 2) Make sure there is enough size to write constituents. While at it, convert the only sizeof() in the driver that uses a type instead of variable.", "cve_priority": "high", "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-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-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-68409", "url": "https://ubuntu.com/security/CVE-2026-68409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: defer link RX stats percpu free to RCU sta_remove_link() frees a removed MLO link's RX stats percpu buffer right away, but defers only the link container to RCU: \tsta_info_free_link(&alloc->info); \tkfree_rcu(alloc, rcu_head); The RX fast path reads link_sta under rcu_read_lock and writes the percpu stats. A reader that resolved link_sta before the removal keeps the pointer. The container stays alive from the kfree_rcu, so the read still works. But the percpu block it points to is already freed. This needs uses_rss. That is when pcpu_rx_stats exists. The full STA teardown frees the deflink stats only after synchronize_net(). The link removal path had no such barrier. The race is hard to win in practice, but the free should still wait for RCU. Free the link together with its data from a single RCU callback, so the percpu block is reclaimed only after readers drain.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20: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-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-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-68412", "url": "https://ubuntu.com/security/CVE-2026-68412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan() If the test against IEEE80211_MAX_SSID_LEN fails, then 'creq' leaks. Use the existing error handling path to fix it.", "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-64566", "url": "https://ubuntu.com/security/CVE-2026-64566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags() When iptfs_skb_add_frags() copies frag references from the source frag walk into a new SKB, it increments the page reference count via __skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the destination SKB's skb_shinfo->flags. If the source SKB carries shared frags (e.g. from a page-pool backed receive path), the new inner SKB will appear to ESP as having privately owned frags. A subsequent esp_input() call for a nested transport-mode SA then takes the no-COW fast path and decrypts in place, writing over pages that are still referenced by the outer IPTFS SKB. This causes kernel-visible memory corruption and can trigger a panic. All other frag-transfer helpers in the kernel (skb_try_coalesce, skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this convention by setting the flag inside the loop immediately after __skb_frag_ref() and nr_frags++, so every exit path that attaches a frag unconditionally propagates SKBFL_SHARED_FRAG.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68415", "url": "https://ubuntu.com/security/CVE-2026-68415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear mode callbacks after failed mode setup xfrm_state_gc_task can run long after a failed IPTFS state setup. In the reproduced case, __xfrm_init_state() cached x->mode_cbs, IPTFS setup returned -ENOMEM before publishing mode_data, and the temporary module reference from xfrm_get_mode_cbs() was dropped immediately. The dead state then kept x->mode_cbs until deferred GC ran after xfrm_iptfs had been unloaded. Clear x->mode_cbs when mode init or clone fails before publishing mode_data. Those states never installed mode-specific state or the long-term IPTFS module pin, so deferred GC has nothing mode-specific to destroy and must not retain a callback table pointer past the temporary lookup reference. The buggy scenario involves two paths, with each column showing the order within that path: failed setup path: 1. cache x->mode_cbs 2. mode setup fails before mode_data 3. drop the temporary module ref 4. dead state keeps x->mode_cbs cached GC/unload path: 1. xfrm_state_put() queues GC work 2. xfrm_iptfs unloads later 3. xfrm_state_gc_task runs 4. GC dereferences stale x->mode_cbs This also covers the failed clone path where clone_state() returns before publishing mode_data. Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y failslab_stacktrace_filter matched xfrm_iptfs frames ack_error=-12 FAULT_INJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrm_state_gc_task RIP: xfrm_state_gc_task+0x142/0x650 Modules linked in: esp4_offload xfrm_user [last unloaded: xfrm_iptfs] Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68418", "url": "https://ubuntu.com/security/CVE-2026-68418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent user-triggered null deref on QP create Previously, the user QP creation path would only attempt to populate iwqp->iwpbl if the user-provided req.user_wqe_bufs field was non-zero. The problem is that iwqp->iwpbl is unconditionally dereferenced later on in irdma_setup_virt_qp. While there was a check for iwqp->iwpbl != NULL, this check would only occur if req.user_wqe_bufs was non-zero. The end result is that a user could send a zero user_wqe_bufs value and trigger a null ptr deref. Fix this by unconditionally calling irdma_get_pbl and bailing if it fails, similar to the CQ and SRQ paths.", "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-68420", "url": "https://ubuntu.com/security/CVE-2026-68420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: reject optional IPTFS templates in outbound policies syzbot reported a stack-out-of-bounds read in xfrm_state_find() which flows from xfrm_tmpl_resolve_one(). Commit 3d776e31c841 (\"xfrm: Reject optional tunnel/BEET mode templates in outbound policies\") disallowed optional tunnel and BEET in outbound policies to prevent this. Later when IPTFS added, it was not covered by that fix and can still trigger the out-of-bounds read; Extend the check to disallow optional IPTFS in outbound policies as well. IPTFS should be identical to tunnel mode. IN and FWD policies are not affected: xfrm_tmpl_resolve_one() is only reachable via the outbound path. Reproducer, before: ip link add dummy0 type dummy ip link set dummy0 up ip addr add 10.1.1.1/24 dev dummy0 ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 mode transport ping -W 1 -c 1 10.1.1.2 PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data. [ 64.168420] ================================================================== [ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844 [ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full) [ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 64.169977] Call Trace: [ 64.169977] [ 64.169977] dump_stack_lvl+0x47/0x70 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] print_report+0x152/0x4b0 [ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0 [ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20 [ 64.169977] ? __virt_addr_valid+0x21b/0x230 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] kasan_report+0xa8/0xd0 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm_dst_hash+0x24/0xc0 [ 64.169977] xfrm_state_find+0xa2d/0x2f90 [ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570 [ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10 [ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 64.169977] ? kernel_text_address+0x5b/0x80 [ 64.169977] ? __kernel_text_address+0xe/0x30 [ 64.169977] ? unwind_get_return_address+0x5e/0x90 [ 64.169977] ? arch_stack_walk+0x8c/0xe0 [ 64.169977] xfrm_tmpl_resolve+0x130/0x200 [ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10 [ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110 [ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10 [ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310 [ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80 [ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10 [ 64.169977] ? ip_route_output_key_hash+0xc6/0x110 [ 64.169977] ? kasan_save_track+0x10/0x30 [ 64.169977] xfrm_lookup_route+0x18/0xe0 [ 64.169977] ip4_datagram_release_cb+0x4c9/0x530 [ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10 [ 64.169977] ? do_raw_spin_lock+0x71/0xc0 [ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 64.169977] release_sock+0xb0/0x170 [ 64.169977] udp_connect+0x43/0x50 [ 64.169977] __sys_connect+0xa6/0x100 [ 64.169977] ? alloc_fd+0x2e9/0x300 [ 64.169977] ? __pfx___sys_connect+0x10/0x10 [ 64.169977] ? preempt_latency ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68421", "url": "https://ubuntu.com/security/CVE-2026-68421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx() put_prev_task_scx() warns when a runnable task drops to a lower sched_class without SCX_OPS_ENQ_LAST, on the assumption that balance_one() would have kept it running. Core scheduling breaks that: a forced-idle SMT sibling reschedules through the core_pick fast path in pick_next_task(), which skips pick_task_scx() and thus balance_one(), so a runnable task can drop to idle with ENQ_LAST unset. Gate the warning on sched_cpu_cookie_match(): a cookie mismatch means core scheduling forced the idle, while a match (or core scheduling off) still catches a genuine missing-ENQ_LAST drop.", "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-68426", "url": "https://ubuntu.com/security/CVE-2026-68426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix stale skb->prev after async crypto steals a GSO segment skb_gso_segment() leaves the segment list head with ->prev pointing at the last segment, an invariant validate_xmit_skb_list() relies on when it sets its tail pointer (tail = skb->prev). When validate_xmit_xfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validate_xmit_skb_list() later does tail->next = skb, writing through that stale pointer -- a use-after-free. Repoint skb->prev at the last retained segment before returning.", "cve_priority": "critical", "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-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-2023-20585", "url": "https://ubuntu.com/security/CVE-2023-20585", "cve_description": "Insufficient checks of the RMP on host buffer access in IOMMU may allow an attacker with privileges and a compromised hypervisor to trigger an out of bounds condition without RMP checks, resulting in a potential loss of confidential guest integrity.", "cve_priority": "low", "cve_public_date": "2026-04-16 19:16:00 UTC" }, { "cve": "CVE-2026-68364", "url": "https://ubuntu.com/security/CVE-2026-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix ISM dc_lock deadlock during suspend [Why] System hang observed during suspend/resume while video is playing. amdgpu_dm_ism_disable() is called under dc_lock and waits for ISM delayed work via disable_delayed_work_sync(). The work handlers themselves take dc_lock, producing an ABBA deadlock when a worker is in flight at suspend time. [How] Split the disable path into two phases with opposite locking contracts: 1. amdgpu_dm_ism_disable() -- quiesces workers, must NOT hold dc_lock. 2. amdgpu_dm_ism_force_full_power() (new) -- drives the ISM FSM back to FULL_POWER_RUNNING, must hold dc_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72064", "url": "https://ubuntu.com/security/CVE-2026-72064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Sync page pool RX frags for CPU MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack.", "cve_priority": "medium", "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-72098", "url": "https://ubuntu.com/security/CVE-2026-72098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: fix buffer overflow in FEC calculation There's a buffer overflow in dm-verity-fec: if (neras && *neras <= v->fec->roots) \tfio->erasures[(*neras)++] = i; This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72248", "url": "https://ubuntu.com/security/CVE-2026-72248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: support IPIP tunnel with direct xmit The combination of IPIP tunnel with direct xmit, eg. bridge device, breaks because no dst_entry is provided to check the skb headroom and to set the iph->frag_off field. This leads to invalid dst usage and can trigger a crash in the tunnel transmit path. Fix this by moving dst_cache and dst_cookie out of the runtime union so that they can be shared by neighbour, xfrm, and direct tunnel flows. For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve route state in these shared fields and release it through the common dst release path. Since dst_entry is now available to the three supported xmit modes and dst_release() already deals with NULL dst, remove the xmit type check in nft_flow_dst_release(). Moreover, skip the check if the dst entry is NULL in nf_flow_dst_check() which is now the case for the direct xmit case. Based on patch from Rein Wei .", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72249", "url": "https://ubuntu.com/security/CVE-2026-72249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: use dst in this direction when pushing IPIP header When pushing the IPIP header, the route of the other direction is used to calculate the headroom, use the route in this direction. Accessing the other tuple to set the IP source and destination is fine because this tuple does not provide such information to avoid storing redundant information. However, this tuple already provides the dst for this direction, this went unnoticed because this bug affects headroom and iph->frag_off only at this stage.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72287", "url": "https://ubuntu.com/security/CVE-2026-72287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the \"normal\" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a \"late\" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72329", "url": "https://ubuntu.com/security/CVE-2026-72329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/liquidio: drop cached VF pci_dev LUT The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST. Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72355", "url": "https://ubuntu.com/security/CVE-2026-72355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix barriering when walking subrequest list Fix the barriering used when walking the subrequest list in retry as there's a possibility of seeing a subreq that's just been added by the application thread.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72412", "url": "https://ubuntu.com/security/CVE-2026-72412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/mm: Fix handling of _PAGE_UNUSED pte bit The _PAGE_UNUSED softbit should not really be lying around. Its sole purpose is to signal to try_to_unmap_one() and try_to_migrate_one() that the page can be discarded instead of being moved / swapped. KVM has no way to know why a page is being unmapped, so it sets the bit on userspace ptes corresponding to unused guest pages every time they get unmapped. KVM has no reasonable way to clear the bit once the page is in use again. While set_ptes() checks and clears the bit, other paths that set new ptes did not. This led to used pages being thrown out as if they were unused, causing guest corruption. Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in set_pte(), i.e. whenever a present pte is getting set. The check in set_ptes() is then redundant and can be removed. Also fix gmap_helper_try_set_pte_unused() to only set the bit if the pte is present; the _PAGE_UNUSED bit is only defined for present ptes and thus should not be set for non-present ptes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72417", "url": "https://ubuntu.com/security/CVE-2026-72417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto() Add sanity check for iph->ihl field in nf_flow_ip4_tunnel_proto() before using it to compute the header size, avoiding out-of-bounds access with malformed IP headers. While at it, use iph->protocol instead of the hardcoded IPPROTO_IPIP constant when setting ctx->tun.proto and reference ctx->tun.hdr_size when updating ctx->offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72442", "url": "https://ubuntu.com/security/CVE-2026-72442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: fix and simplify IP6IP6 tunnel handling Fix nf_flow_ip6_tunnel_proto() to use pskb_may_pull() instead of skb_header_pointer() to ensure the outer IPv6 header is in the skb headroom, which is required for subsequent packet processing. Move ctx->offset update inside the IPPROTO_IPV6 conditional block since it should only be adjusted when an IP6IP6 tunnel is actually detected. Simplify the rx path by removing ipv6_skip_exthdr() and checking ip6h->nexthdr directly, as the flowtable fast path only handles simple IP6IP6 encapsulation without extension headers. Drop the tunnel encapsulation limit destination option support from the tx path to match, since the rx path no longer handles extension headers. Remove the encap_limit parameter from nf_flow_offload_ipv6_forward(), nf_flow_tunnel_ip6ip6_push() and nf_flow_tunnel_v6_push(), along with the ipv6_tel_txoption struct and related headroom/MTU adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72463", "url": "https://ubuntu.com/security/CVE-2026-72463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix dev use-after-free in xfrm async resumption xfrm async resumption hold skb->dev refcnt until after transport_finish. However, xfrm_rcv_cb may modify skb->dev to tunnel dev without taking device reference, such as vti_rcv_cb. The subsequent async resumption will decrement the tunnel device's reference count, which lead to uaf of tunnel dev and refcnt leak of orig dev as below: unregister_netdevice: waiting for vti1 to become free. Usage count = -2 Stash the original skb->dev to fix refcnt imbalance. The new skb->dev set by xfrm_rcv_cb can race with device teardown. Extend rcu protection over xfrm_rcv_cb and transport_finish to prevent races.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72477", "url": "https://ubuntu.com/security/CVE-2026-72477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: call _ntfs_bad_inode() when failing to rename It is safe to call _ntfs_bad_inode on live inodes since: commit 519b078998ce (\"fs/ntfs3: Exclude call make_bad_inode for live nodes.\") The WARN_ON was added when it wasn't safe by: commit d99208b91933 (\"fs/ntfs3: cancle set bad inode after removing name fails\") Replace the WARN_ON with a call to _ntfs_bad_inode() to prevent further operations on the inconsistent inode.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72493", "url": "https://ubuntu.com/security/CVE-2026-72493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: serialize netif_running() check in enqueue_to_backlog() Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup(). The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit). Commit e9e4dd3267d0 (\"net: do not process device backlog during unregistration\") introduced a lockless netif_running() check in enqueue_to_backlog() to prevent queuing packets to an unregistering device. However, this creates a TOCTOU race window. A lockless transmitter (like veth_xmit) can pass the check before dev_close() clears IFF_UP. If the transmitter is then delayed, flush_all_backlogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed. Fix this by moving the netif_running() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netif_running() after the flush/close completes (so it gets dropped).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72494", "url": "https://ubuntu.com/security/CVE-2026-72494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Replace waitqueue and flag with completion The driver previously used a waitqueue along with an explicit request_done flag, but without proper barriers around request_done. An earlier patch by Gui-Dong Han attempted to fix this by adding the missing memory barriers. Rather than adding the barriers, this patch replaces the waitqueue+flag with a completion, which is designed for this exact purpose.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72496", "url": "https://ubuntu.com/security/CVE-2026-72496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Proper rollback if the ioremap fails bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74269", "url": "https://ubuntu.com/security/CVE-2026-74269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt: fix head underflow on XDP head-grow The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free. The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with this commit applied causes the test to run successfully to completion. The other rx_skb_func implementations don't have this issue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74350", "url": "https://ubuntu.com/security/CVE-2026-74350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate fast symlink target during inode read ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment. A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer. Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated. This keeps malformed fast symlinks from reaching the read path. Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x19f/0x330 (?:?) kasan_report+0xe0/0x110 (?:?) kasan_check_range+0x105/0x1b0 (?:?) __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72495", "url": "https://ubuntu.com/security/CVE-2026-72495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid repeated requests to allocate WC pages Applications can request multiple WC pages for the same ucontext. As of now, only 1 WC page per ucontext is supported. Add a lock to avoid concurrent access and a check to fail repeated requests. Also, if the mmap entry insert fails for the WC, free the Doorbell page index mapped for the WC page.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72501", "url": "https://ubuntu.com/security/CVE-2026-72501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Initialize dpi variable to zero dpi is initialized only for BNXT_RE_ALLOC_WC_PAGE, but copied for all the cases. So initialize the dpi to 0.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72278", "url": "https://ubuntu.com/security/CVE-2026-72278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Re-translate VNCR before injecting abort KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor updates and MMU faults.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68083", "url": "https://ubuntu.com/security/CVE-2026-68083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix path resolution in ksmbd_vfs_kern_path_create The SMB2 open lookup is rooted at the share with LOOKUP_BENEATH, but the create/mkdir/hardlink sink is not: ksmbd_vfs_kern_path_create() builds an absolute path with convert_to_unix_name() and resolves it from AT_FDCWD via start_creating_path(), so a \"..\" component is walked from the real filesystem root and escapes the export. An authenticated client races a missing path component so the rooted open lookup returns -ENOENT (taking the create branch) while the same component is present (a directory) when the create walk runs; the create then resolves \"..\" out of the share. Root the create walk at the share like the lookup and rename paths already are: resolve the parent with vfs_path_parent_lookup(..., LOOKUP_BENEATH, &share_conf->vfs_path) and create the final component with start_creating_noperm(). convert_to_unix_name() then has no callers and is removed.", "cve_priority": "high", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-68457", "url": "https://ubuntu.com/security/CVE-2026-68457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use opener credentials for FSCTL mutations SET_SPARSE, SET_ZERO_DATA and SET_COMPRESSION operate on an open SMB handle but call VFS xattr, fallocate or fileattr helpers with the current ksmbd worker credentials. Those helpers can revalidate inode permissions, ownership and LSM policy independently of the SMB handle access mask. Run each operation with the credentials captured in the target file when the handle was opened. Keep credential handling local to these single-file FSCTLs rather than applying session credentials to the complete IOCTL handler, which also contains handle-less and multi-handle operations.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72041", "url": "https://ubuntu.com/security/CVE-2026-72041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: use sk_msg_free_partial to fix partial send sk_msg_free_partial() ensures consistency of the skmsg at every iteration, without having to manually handle uncharges and offsets. This simplifies the code, and fixes some bugs in skmsg accounting when we don't send the full contents.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72046", "url": "https://ubuntu.com/security/CVE-2026-72046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing.", "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-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21: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-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72137", "url": "https://ubuntu.com/security/CVE-2026-72137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: nat_keepalive: avoid double free on send error nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6 send helper reports an error. That cleanup is only correct before the skb is handed to the output path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the networking stack may already have consumed the skb before returning an error, so freeing it again is unsafe. Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4() and nat_keepalive_send_ipv6(), where the caller still owns the skb, and keep nat_keepalive_send() responsible only for family dispatch and the unsupported-family cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72139", "url": "https://ubuntu.com/security/CVE-2026-72139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: defer md5sig_info kfree past RCU grace period in tcp_connect The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: \tif (needs_md5) { \t\ttcp_ao_destroy_sock(sk, false); \t} else if (needs_ao) { \t\ttcp_clear_md5_list(sk); \t\tkfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); \t} Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with tcp-diag]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72191", "url": "https://ubuntu.com/security/CVE-2026-72191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: validate split-point offset in indx_insert_into_buffer indx_insert_into_buffer() computes used = used1 - to_copy - sp_size; memmove(de_t, Add2Ptr(sp, sp_size), used - le32_to_cpu(hdr1->de_off)); where sp and sp_size come from hdr_find_split(). hdr_find_split() walks entries by le16_to_cpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFS_DE). index_hdr_check(), the on-load gatekeeper, only validates header-level fields (used, total, de_off) and does not walk per-entry sizes. A crafted NTFS image whose leaf INDEX_HDR reports used == total but contains one interior NTFS_DE with size = 0xFFF0 therefore passes validation, descends to indx_insert_into_buffer() through the ntfs_create() -> indx_insert_entry() path, and makes hdr_find_split() return an sp whose sp_size (0xFFF0) greatly exceeds the remaining bytes in the buffer. The u32 subtraction underflows and the memmove count becomes a near-4-GiB value, producing an out-of-bounds kernel write that corrupts adjacent allocations and panics the kernel. Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a single 'touch' inside the mounted directory; crash site resolves to fs/ntfs3/index.c at the memmove. Trigger requires only local mount of an attacker-supplied filesystem image (USB, loopback, or removable media auto-mount). Reject the split whenever the chosen sp plus its declared size already extends past hdr1->used. This is the minimal fix; it preserves the existing hdr_find_split() contract and relies on the same out: cleanup path as the pre-existing error returns. A prior OOB read in the very same indx_insert_into_buffer() memmove was fixed in commit b8c44949044e (\"fs/ntfs3: Fix OOB read in indx_insert_into_buffer\") by tightening hdr_find_e(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdr_find_split(), not hdr_find_e(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72217", "url": "https://ubuntu.com/security/CVE-2026-72217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing xdr_buf_to_bvec() writes a bio_vec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it. rq_bvec, the array passed by nfsd_vfs_write(), is allocated to exactly rq_maxpages entries with no slack. The OOB store can land in adjacent slab memory; the bv_len and bv_offset fields written there are derived from client-supplied RPC payload sizes. Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72220", "url": "https://ubuntu.com/security/CVE-2026-72220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp->rq_procinfo->pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72221", "url": "https://ubuntu.com/security/CVE-2026-72221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: wait for in-flight TLS handshake callback when cancel loses race When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed. The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result. If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue. If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed. Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed to fire because handshake_complete() invokes svc_tcp_handshake_done() unconditionally once it has set HANDSHAKE_F_REQ_COMPLETED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72222", "url": "https://ubuntu.com/security/CVE-2026-72222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: pin svc_xprt across the asynchronous TLS handshake callback svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of(). Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done. The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry. Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all(). [cel: rewrote commit message to describe the actual change]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72277", "url": "https://ubuntu.com/security/CVE-2026-72277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the simpler thing for now and just reject everything that isn't memory.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72279", "url": "https://ubuntu.com/security/CVE-2026-72279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR KVM currently maps the L1 VNCR into the host stage-1 by relying entirely on the permissions of the guest stage-1. At the same time, it is entirely possible that the backing PFN is read-only (e.g. RO memslot), meaning that the L1 VNCR should use at most a read-only mapping. Cache the writability of the PFN in the VNCR TLB and use it to constrain the resulting fixmap permissions. Promote VNCR permission faults to an SEA in the case where the guest attempts to write to a read-only endpoint. Conveniently, this also plugs a page leak found by Sashiko [*] resulting from the early return for a read-only PFN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72288", "url": "https://ubuntu.com/security/CVE-2026-72288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling Hyunwoo Kim reports some really bad races should the following situation occur: - LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C If the last two race nicely enough, vgic_prune_ap_list() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows. The fix is two-fold: - Before dropping the irq and ap_list locks, take a reference on the irq - Do not try to handle migration of the pending bit: there is no expectation that this state is retained, as per the architecture With that, we're sure that the interrupt is still around, and we safely remove it from the AP list as it has no target at this stage (unless another interrupt fires, but that's another story).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "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-72317", "url": "https://ubuntu.com/security/CVE-2026-72317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: pin upper rpc_clnt across the TLS connect_worker The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt. The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported. Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one. The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72318", "url": "https://ubuntu.com/security/CVE-2026-72318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate DFS referral string offsets parse_dfs_referrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server. Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative max_len is then passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds. Validate each string offset before deriving the string pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72320", "url": "https://ubuntu.com/security/CVE-2026-72320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_lookup: fix catchall element handling with inverted lookups nft_lookup_eval() decides whether a lookup matched (`found`) from the direct set lookup and priv->invert before falling back to the catchall element used by interval sets (e.g. nft_set_rbtree) for the open-ended default range. Since `found` is never recomputed after `ext` is replaced by the catchall lookup, inverted lookups (NFT_LOOKUP_F_INV, \"!= @set\") can wrongly match or wrongly skip the catchall element, producing the wrong verdict. Fold the catchall lookup into `ext` before computing `found`, matching the order already used by nft_objref_map_eval().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72366", "url": "https://ubuntu.com/security/CVE-2026-72366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_create_write_req() to handle async cache object creation netfs_create_write_req() will skip caching if the fscache cookie is disabled, but this is a problem because async cache object creation might not have got far enough yet that has been enabled - thereby causing the call to fscache_begin_write_operation() to be skipped. Fix this by removing the checks on the cookie and delegating this to fscache_begin_write_operation().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72381", "url": "https://ubuntu.com/security/CVE-2026-72381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of fp->owner.name in durable handle owner check Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d (\"ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd\") made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized. BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8 Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72393", "url": "https://ubuntu.com/security/CVE-2026-72393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: don't cache shinfo across skb realloc fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb including the shared info. We can't use the pointer calculated before the call. BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0 Read of size 4 at addr ff110000262edd98 by task swapper/5/0 Call Trace: fbnic_tx_lso.isra.0+0x668/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 Allocated by task 8653: __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xcc/0x6c0 sock_alloc_send_pskb+0x327/0x3f0 __ip_append_data+0x188b/0x47a0 ip_make_skb+0x24a/0x300 udp_sendmsg+0x14d2/0x21e0 Freed by task 0: kfree+0x123/0x5a0 pskb_expand_head+0x36c/0xfa0 fbnic_tx_lso.isra.0+0x500/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 sch_direct_xmit+0x25b/0x1100 The buggy address belongs to the object at ff110000262edc40 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 344 bytes inside of freed 640-byte region [ff110000262edc40, ff110000262ede", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72398", "url": "https://ubuntu.com/security/CVE-2026-72398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: add INIT verification after cookie unpacking In SCTP handshake, the INIT chunk is initially processed by the server and embedded into the cookie carried in INIT-ACK. The client then returns this cookie via COOKIE-ECHO, where the server unpacks it and reconstructs the original INIT chunk. When cookie authentication is enabled, the cookie contents are protected against tampering, so reusing the unpacked INIT without re-verification is safe. However, when cookie authentication is disabled, the reconstructed INIT can no longer be trusted. In this case, the INIT must be explicitly validated after unpacking to avoid processing potentially tampered data. Add sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO processing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook()) when cookie_auth_enable is disabled. On failure, the new association is freed and the packet is discarded. Also tighten cookie validation in sctp_unpack_cookie() by verifying the embedded chunk type is SCTP_CID_INIT before treating it as an INIT chunk. Finally, update sctp_verify_init() to validate parameter bounds using the actual embedded INIT length instead of chunk->chunk_end, since the INIT stored in COOKIE-ECHO may not span the entire chunk buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72399", "url": "https://ubuntu.com/security/CVE-2026-72399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: check the number of BDs needed for xdp_frame The size of xdp_redirect_arr array is ENETC_MAX_SKB_FRAGS. However, the number of fragments contained in xdp_frame may be greater than or equal to ENETC_MAX_SKB_FRAGS, which will cause the access to xdp_redirect_arr to be out of bounds.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72429", "url": "https://ubuntu.com/security/CVE-2026-72429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix type confusion of dst_entry IOAM uses a dummy dst_entry(null_dst) to mark that the destination should not be changed after the transformation. This dst is stored in the IOAM lwt state and may be passed to dst_cache_set_ip6(). However, the IPv6 dst cache path eventually calls rt6_get_cookie(), which treats the dst_entry as part of a struct rt6_info. Since the null_dst was embedded directly as a struct dst_entry in struct ioam6_lwt, this resulted in an invalid cast and rt6_get_cookie() reading fields from the wrong object. In practice, the wrong cookie is not used while dst->obsolete is zero, but rt6_get_cookie() may also access per-cpu value when rt->sernum is zero. In this case, rt->sernum aliases ioam6_lwt::cache::reset_ts, which can become zero, making this a potential invalid pointer access. Fix this by embedding a full struct rt6_info for the dummy IPv6 route and passing its dst member to the dst APIs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72436", "url": "https://ubuntu.com/security/CVE-2026-72436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash types Sashiko pointed out that there are a few lockless RCU readers using test_bit() which is a relaxed atomic operation and provides no memory barrier guarantees. Use test_bit_acquire() instead where the operation may run parallel with add/del/gc, i.e. is not one from the next cases - protected by region lock - in a set destroy phase - in a new/temporary set creation phase", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72451", "url": "https://ubuntu.com/security/CVE-2026-72451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix xfrm state cache insertion race The xfrm input state cache insertion code checks the validity of the state before acquiring the global xfrm_state_lock. Thus it's possible for someone else to kill the state after it passed the validity check, and then the insertion will add the dead state to the cache. Fix this by moving the validity check inside the lock. This entire function is called on the input path, where BH must be off (e.g., the caller of this function xfrm_input acquires its spinlocks without disabling BH). So there is no need to disable BH here or take the RCU read lock. Remove both and replace them with an assertion that trips if BH is accidentally enabled on some future calling path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72472", "url": "https://ubuntu.com/security/CVE-2026-72472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: use nfsi->rwsem to protect traversal of the file lock list Lingfeng identified a bug and suggested two solutions, but both appear to have issues. Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case. Furthermore, after commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk. Regarding the bug fixed by commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), it has been resolved after commit 0460253913e5 (\"NFSv4: nfs4_do_open() is incorrectly triggering state recovery\") because all slots are drained before calling nfs4_do_reclaim, which prevents concurrent stateid changes along this path. Also, nfs_delegation_claim_locks does not cause this concurrency either since when _nfs4_proc_setlk is called with NFS_DELEGATED_STATE, no RPC is sent, so nfs4_lock_done is not called. Therefore, nfs4_lock_delegation_recall from nfs_delegation_claim_locks is the first time the stateid is set.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72473", "url": "https://ubuntu.com/security/CVE-2026-72473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decouple req recycling from RPC completion rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer. Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off. The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry. Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied. Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected. Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released. The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74310", "url": "https://ubuntu.com/security/CVE-2026-74310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/net: complete zerocopy ubufs only once vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74345", "url": "https://ubuntu.com/security/CVE-2026-74345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix endpoint/socket association handling Disassociating a socket from an endpoint via siw_socket_disassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within. This fixes a: BUG: KASAN: slab-use-after-free in siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1053 drivers/infiniband/sw/siw/siw_cm.c:1075) which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74361", "url": "https://ubuntu.com/security/CVE-2026-74361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: fix FDP fdpcidx bounds check The fdpcidx bounds check sets n = NUMFDPC + 1 but used > instead of >=, incorrectly accepting fdp_idx when it equals n (i.e. NUMFDPC + 1).", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74401", "url": "https://ubuntu.com/security/CVE-2026-74401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix add msg handle in send_queue ordered In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as \"before(mh->seq, seq)\" will stop to check for older sequence numbers that are ordered in the tail of \"node->send_queue\". The side effects of not having it correct ordered regarding \"before(mh->seq, seq)\" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74406", "url": "https://ubuntu.com/security/CVE-2026-74406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74428", "url": "https://ubuntu.com/security/CVE-2026-74428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix double unlock in rxrpc_recvmsg() Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74433", "url": "https://ubuntu.com/security/CVE-2026-74433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix UAF in rxgk_issue_challenge() Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74434", "url": "https://ubuntu.com/security/CVE-2026-74434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Don't move a peeked OOB message onto the pending queue rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so only unlink it from recvmsg_oobq and then move it onto pending_oobq or free it when the message is actually consumed.", "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-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-74439", "url": "https://ubuntu.com/security/CVE-2026-74439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clear Present bit before tearing down scalable-mode context entry device_pasid_table_teardown() zeroes the 128-bit scalable-mode context entry with context_clear_entry() while the Present bit is still set. This creates a window where the hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behavior or spurious faults. The context-cache invalidation is issued only after the entry has been zeroed, and intel_pasid_free_table() then frees the PASID directory pages, so the IOMMU can keep walking a stale Present=1 entry that points at freed memory. While x86 provides strong write ordering, the compiler may reorder the two 64-bit writes to the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Commit c1e4f1dccbe9d (\"iommu/vt-d: Clear Present bit before tearing down context entry\") fixed this exact pattern in domain_context_clear_one() and the copied-context path, but device_pasid_table_teardown() was not converted. Align it with the \"Guidance to Software for Invalidations\" in the VT-d spec, Section 6.5.3.3, using the same ownership handshake as the sibling fix: clear only the Present bit, flush it to the IOMMU, perform the context-cache invalidation, and only then zero the rest of the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2165483, 2165484, 2165407, 2166547, 2166443, 2166356, 2165872, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165407, 2165040, 2161748, 2163508, 2163214, 2162904, 2162045, 2164967, 2160082, 2164504, 2156316, 2164716, 2164516, 2163375, 2162803, 2163062, 2132119, 2163293, 2160200, 2158858, 2162704, 2162695, 2164666, 2164666, 2163121 ], "changes": [ { "cves": [ { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-68105", "url": "https://ubuntu.com/security/CVE-2026-68105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix kernel panic during driver load failure Avoid kernel panic if MES init fails during driver load. The KIQ ring is falsely marked as ready as ASICs that use MES, KIQ is owned by MES. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] Call Trace: gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280 __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53 (cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68109", "url": "https://ubuntu.com/security/CVE-2026-68109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68114", "url": "https://ubuntu.com/security/CVE-2026-68114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit e4d99e04b2e9b13b97d3b17804c735f62689db23)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68431", "url": "https://ubuntu.com/security/CVE-2026-68431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate minimum PDU size for transform requests The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68138", "url": "https://ubuntu.com/security/CVE-2026-68138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: serialize qdisc_rtab_list against concurrent get/put qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68082", "url": "https://ubuntu.com/security/CVE-2026-68082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix two unsafe bare decodes in decode_lockers() decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-08 10:16:00 UTC" }, { "cve": "CVE-2026-68159", "url": "https://ubuntu.com/security/CVE-2026-68159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68163", "url": "https://ubuntu.com/security/CVE-2026-68163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_vma_mapped: fix device-private PMD handling Commit 65edfda6f3f2 (\"mm/rmap: extend rmap and migration support device-private entries\") introduced the concept of device-private PMD entries, but did not correctly update the rmap walk code to account for them. As a result, when page_vma_mapped_walk() encounters device-private PMD entries, it takes no action other than to acquire the PMD lock and exit. However this is highly problematic for two reasons - firstly, device private entries possess a PFN so check_pmd() needs to be called to ensure an overlapping PFN range. Secondly, and more importantly, if PVMW_MIGRATION is set the caller assumes the returned entry is a migration entry, resulting in memory corruption when the caller tries to interpret the device private entry as such. In addition, commit 146287290023 (\"mm/huge_memory: implement device-private THP splitting\") allowed device private PMDs to be split like THP mappings, but again did not update this code path. As a result, we might race a PMD split prior to acquiring the PMD lock. This patch addresses all of these issues by invoking check_pmd(), ensuring PMVW_MIGRATION is not set and checks whether a split raced us we do for PMD THP and migration entries. Instead of checking for a subset of the cases after taking the pmd_lock(), put device-private along with pmd_trans_huge() and pmd_is_migration_entry(). Also remove thp_migration_supported() as it is already guarded by pmd_is_migration_entry(). [akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68166", "url": "https://ubuntu.com/security/CVE-2026-68166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: prevent registration of special VMAs Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68170", "url": "https://ubuntu.com/security/CVE-2026-68170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix stale skb->sk reference on subflow close The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68177", "url": "https://ubuntu.com/security/CVE-2026-68177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Delay module ref count for \"enable_event\" trigger Triggers are now delayed from freeing, but can still be triggered until after the RCU grace period has ended. The freeing of the enable_event data is put into the private_data_free() callback, but the put of the module refcount is done immediately. It is possible that if a module is removed that has an event that would enable (or disable) it is still active, it can read the data of the module after it is removed causing a use-after-free bug. Move the trace_event_put_ref() that releases the module into the delayed callback so that the module can not be removed until any reference to its events are finished.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68191", "url": "https://ubuntu.com/security/CVE-2026-68191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix NULL pointer dereference in rhash table destroy When unbinding the ath12k driver, kernel NULL pointer dereferences occur in irq_work_sync() called from rhashtable_destroy(). Two hash tables are affected: 1. ath12k_link_sta hash table in ath12k_base 2. ath12k_dp_link_peer hash table in ath12k_dp The issue happens because the destroy functions are called unconditionally in cleanup paths, but the hash tables are only initialized late in their respective init functions. If the device was never fully started or if the init functions failed before initializing the hash tables, the pointers will be NULL. The issues are always reproducible from a VM because the MSI addressing initialization is failing. Call trace for ath12k_link_sta_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_link_sta_rhash_tbl_destroy+0x19/0x40 [ath12k] ath12k_core_stop+0xe/0x80 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Call trace for ath12k_dp_link_peer_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_dp_link_peer_rhash_tbl_destroy+0x29/0x50 [ath12k] ath12k_dp_cmn_device_deinit+0x21/0x140 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Fix this by adding NULL checks before calling rhashtable_destroy() in both destroy functions. The NULL check approach was chosen because the rhashtable pointer serves as the initialization state indicator. The init can fail at various points, leaving some components uninitialized. Checking the pointer directly is simpler than adding separate state flags that would need synchronization.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64586", "url": "https://ubuntu.com/security/CVE-2026-64586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: drain bus_reset work on device removal brcmf_fw_crashed() and the debugfs \"reset\" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs \"reset\" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. 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-68208", "url": "https://ubuntu.com/security/CVE-2026-68208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: Fix the error code of devm_kzalloc() in vip_probe_slice() In vip_probe_slice(), the error check for devm_kzalloc() incorrectly uses PTR_ERR_OR_ZERO() which returns 0 for NULL pointer. Return -ENOMEM for devm_kzalloc() failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68224", "url": "https://ubuntu.com/security/CVE-2026-68224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mali-c55: Fix possible ERR_PTR in enable_streams The media_pad_remote_pad_unique() function returns either a valid pointer or an ERR_PTR() on failure (-ENOTUNIQ if multiple links are enabled, -ENOLINK if no connected pad is found). The return value was assigned directly to isp->remote_src and dereferenced in the next line without checking for errors, which could lead to an ERR_PTR dereference. Add proper error checking with IS_ERR() before dereferencing the pointer. Also set isp->remote_src to NULL on error to maintain consistency with other error paths in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68237", "url": "https://ubuntu.com/security/CVE-2026-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: fix indefinite fence wait during GPU reset pre_reset only force-completes fences of MAPPED queues. A queue in any other state (e.g. mid-eviction) keeps its last_fence pending; after a GPU reset that fence never signals, so the eviction/suspend worker and process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and wedge the machine: INFO: task kworker/6:28 blocked for more than 120 seconds. Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu] Call Trace: dma_fence_wait_timeout+0x7e/0x130 amdgpu_userq_evict+0x67/0x140 [amdgpu] amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu] process_scheduled_works+0xa6/0x420 Force-complete every queue's fence regardless of state. The unmap and mark-hung step stays gated on MAPPED, since unmapping a queue that is not mapped is invalid. (cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68240", "url": "https://ubuntu.com/security/CVE-2026-68240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: publish dpagemap early to avoid device mapping leak on error drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68242", "url": "https://ubuntu.com/security/CVE-2026-68242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix NULL deref on sched_engine alloc failure Avoid using intel_context_put() before intel_context_init() in execlists_create_virtual() as the kref_put() inside would lead to NULL deref on the IOCTL path when sched_engine allocation fails. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68254", "url": "https://ubuntu.com/security/CVE-2026-68254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: require valid min/max vfreq for VRR Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68436", "url": "https://ubuntu.com/security/CVE-2026-68436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use kvzalloc to allocate struct dc struct dc has grown large over time (most of it the two inlined dc_scratch_space copies) and now sits close to the page allocator's 4 MiB contiguous allocation limit. Its actual size is not fixed by the source alone, it also depends on the compiler and the .config, so it can easily cross 4 MiB, e.g. with a newer GCC or a config change. dc_create() allocates it with kzalloc(). Once struct dc exceeds 4 MiB the request is rounded up to order 11 (8 MiB), which is above MAX_PAGE_ORDER, so the page allocator warns and returns NULL. dc_create() then fails, DM init fails and amdgpu probe aborts with -EINVAL: WARNING: mm/page_alloc.c:5197 at __alloc_frozen_pages_noprof+0x2f9/0x380 dc_create+0x38/0x660 [amdgpu] amdgpu_dm_init+0x2d9/0x510 [amdgpu] dm_hw_init+0x1b/0x90 [amdgpu] amdgpu_device_init.cold+0x150d/0x1e13 [amdgpu] amdgpu_driver_load_kms+0x19/0x80 [amdgpu] amdgpu_pci_probe+0x1e2/0x4c0 [amdgpu] dc_create() then returns NULL and DM init fails, which aborts the whole GPU init and makes amdgpu probe fail with -EINVAL (\"hw_init of IP block failed -22\"), leaving the display unusable. The subsequent amdgpu_irq_put() warnings during teardown are just fallout of unwinding a half-initialized device. struct dc is a software-only bookkeeping structure that is never handed to hardware DMA and is only ever kept as an opaque pointer, so it does not require physically contiguous memory. Allocate it with kvzalloc() (and free it with kvfree()) so that the allocator can fall back to vmalloc() when a contiguous allocation of that size is not available, which also avoids the MAX_PAGE_ORDER warning entirely. v2: - Rebase to amd-staging-drm-next. (cherry picked from commit 991e0516a8072f2292681c6ae98a924ab0e32575)", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68447", "url": "https://ubuntu.com/security/CVE-2026-68447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size from hardware without bounding it to the allocated BO region. If the HW field is larger than the queue's control stack allocation, memcpy reads past the BO into adjacent GTT memory and can leak kernel data to userspace. Store the page-aligned control stack BO size in mqd_manager and clamp checkpoint copies and reported checkpoint sizes to min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound for multi-XCC v9.4.3 checkpoint layout. (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3)", "cve_priority": "high", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68264", "url": "https://ubuntu.com/security/CVE-2026-68264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: Reset current_op in xe_pt_update_ops_init() xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it. After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind. Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry. Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(). v2 (Matt): - Add details in commit message. - Add Fixes tag and Cc to stable@vger.kernel.org (cherry picked from commit 046045543e530605c441063535e7dca0075369a6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68265", "url": "https://ubuntu.com/security/CVE-2026-68265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO's tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference (cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68267", "url": "https://ubuntu.com/security/CVE-2026-68267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists Unconditionally whitelisting OA registers is a security violation. Set RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers don't get whitelisted by default after probe, gt reset, resume and engine reset. (cherry picked from commit 90511bdcfda97211c01f1d945d4ea616578d8fca)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68273", "url": "https://ubuntu.com/security/CVE-2026-68273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68274", "url": "https://ubuntu.com/security/CVE-2026-68274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix buffer overflow in steered register list allocation The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt->fuse_topo.g_dss_mask, ...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68283", "url": "https://ubuntu.com/security/CVE-2026-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free freeing trigger private data Commit 61d445af0a7c (\"tracing: Add bulk garbage collection of freeing event_trigger_data\") moved the kfree() of event_trigger_data to a kthread that runs tracepoint_synchronize_unregister() before freeing. That removed the synchronization the trigger .free callbacks used to get implicitly and inline from trigger_data_free(). event_hist_trigger_free(), event_hist_trigger_named_free() and event_enable_trigger_free() free their satellite data (hist_data, cmd_ops, enable_data) right after trigger_data_free() returns. With the synchronization now deferred to the kthread, a concurrent tracepoint handler can still reach that data through the list_del_rcu()'d trigger, causing a use-after-free. The histogram teardown must stay synchronous: remove_hist_vars() and unregister_field_var_hists() have to detach a synthetic event from the histogram before the trigger-removal write returns, otherwise a following command races in and the synthetic-event removal fails with -EBUSY, as the trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait with the correct barrier - tracepoint_synchronize_unregister(), matching the free kthread - before freeing. The enable trigger has no such synchronous requirement, and a blocking synchronize there would re-serialize the path that commit deliberately deferred. Give it an optional private_data_free() callback that the free kthread runs after its grace period, and free enable_data from there.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68286", "url": "https://ubuntu.com/security/CVE-2026-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68287", "url": "https://ubuntu.com/security/CVE-2026-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix size calculations for 64-bit attributes net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68288", "url": "https://ubuntu.com/security/CVE-2026-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68289", "url": "https://ubuntu.com/security/CVE-2026-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68291", "url": "https://ubuntu.com/security/CVE-2026-68291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix max_vport related crash on allocation error during init Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000 [ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000 [ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20 [ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000 [ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0 [ 320.417385] PKRU: 55555554 [ 320.417398] Call Trace: [ 320.417412] [ 320.417429] pci_device_remove+0x42/0xb0 [ 320.417459] device_release_driver_internal+0x1a9/0x210 [ 320.417492] driver_detach+0x4b/0x90 [ 320.417516] bus_remove_driver+0x70/0x100 [ 320.417539] pci_unregister_driver+0x2e/0xb0 [ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0 [ 320.417592] ? kmem_cache_free+0x31e/0x550 [ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190 [ 320.417644] ? do_syscall_64+0x38/0x6b0 [ 320.417665] do_syscall_64+0xc8/0x6b0 [ 320.417683] ? clear_bhb_loop+0x30/0x80 [ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 320.417727] RIP: 0033:0x7f963bb30beb", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68303", "url": "https://ubuntu.com/security/CVE-2026-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hvs/v3d: Fix null dereference in unbind The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68312", "url": "https://ubuntu.com/security/CVE-2026-68312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and cifs_close_deferred_file_under_dentry(), when a pending deferred close is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to add the file to the local processing list may fail under memory pressure. The loop breaks immediately, but the cancelled work is no longer pending (it would have called _cifsFileInfo_put()), and the cfile is never added to file_head for processing. The cifsFileInfo reference and the open server handle both leak. Fix by saving the cfile that failed allocation in a local variable, breaking as before, and calling _cifsFileInfo_put() on it after releasing the lock. Any files later in the iteration are unaffected since their deferred work is still pending and will fire normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68316", "url": "https://ubuntu.com/security/CVE-2026-68316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Fix element size accounting for cmd stream validation There are 2 issues with the element size handling in the command stream validation which result in too small of a size calculated when the element size is 16/32/64 bits. For NHWC format, the element size is simply missing from the calculation. The bitfield for the element size is different between IFM/IFM2 and OFM. IFM and IFM2 encode the precision in parameter bits 2:3, while OFM uses bits 1:2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68440", "url": "https://ubuntu.com/security/CVE-2026-68440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix heap overflow when reading module EEPROM txgbe_read_eeprom_hostif() always copies round_up(length, 4) bytes into the caller buffer, which ethtool allocates with exactly 'length' bytes. A non-4-aligned length therefore causes an out-of-bounds write. Copy only the remaining bytes on the final dword instead.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68323", "url": "https://ubuntu.com/security/CVE-2026-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: serialize udp bearer replicast list updates tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68441", "url": "https://ubuntu.com/security/CVE-2026-68441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected. This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d (\"bpf: add bpf_redirect() helper\"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available. commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs. Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a wrapper around tcf_classify() for use by qdisc classify functions and tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT, the wrapper converts it to TC_ACT_SHOT, dropping the packet rather than letting it continue silently. Dropping is preferred over letting the packet through because the user immediately sees packet loss. Silently passing the packet through would hide the problem and leave the user wondering why their redirect is not working. The clsact fast path, tc_run() continues to call tcf_classify() directly and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by sch_handle_egress/ingress() calling skb_do_redirect() as before.", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68337", "url": "https://ubuntu.com/security/CVE-2026-68337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject redirect helpers without a bpf_net_context The bpf_redirect*() helpers and skb_do_redirect() obtain the per-task bpf_redirect_info via bpf_net_ctx_get_ri(), which dereferences the current->bpf_net_context unconditionally. That context is established on the paths that run tc BPF such as sch_handle_{ingress,egress}(), *except* for the case where {cls,act}_bpf was attached to a proper qdisc. A program running from there reaches the NULL deref in two ways: * It calls bpf_redirect() directly, which dereferences the context at the top of the helper: tc qdisc add dev eth0 root handle 1: red limit 1MB min 10KB max 20KB \\ avpkt 1000 burst 100 qevent early_drop block 10 tc filter add block 10 pref 1 bpf obj redirect.o * It simply returns TC_ACT_REDIRECT without helper call: tcf_qevent_handle() then dispatches to skb_do_redirect(), which dereferences the context Rather than extending bpf_net_context management into the qdisc path, make the redirect helpers refuse to operate when no context exists, and have tcf_qevent_handle() drop a TC_ACT_REDIRECT verdict instead of calling skb_do_redirect(). Previous behaviour was a crash, so nothing regresses by not supporting it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68345", "url": "https://ubuntu.com/security/CVE-2026-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm_mpam: guard MBWU state before adding it to garbage __destroy_component_cfg() adds each RIS mbwu_state object to the MPAM garbage list when destroying component configuration. However, mbwu_state is allocated per RIS and only for RISes with MBWU monitors. A component can therefore have comp->cfg allocated while some RISes still have ris->mbwu_state set to NULL. Passing a NULL mbwu_state to add_to_garbage() dereferences the NULL pointer inside the macro. Skip RISes that do not have an mbwu_state object before adding them to the garbage list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68347", "url": "https://ubuntu.com/security/CVE-2026-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68375", "url": "https://ubuntu.com/security/CVE-2026-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle partially initialized auxiliary devices bnxt_aux_devices_init() calls auxiliary_device_init() before all fields used by bnxt_aux_dev_release() are initialized. After auxiliary_device_init() succeeds, later errors must unwind with auxiliary_device_uninit(), which invokes the release callback. The release callback assumes that aux_priv->id, aux_priv->edev, edev->net and edev->ulp_tbl are all populated. If allocation fails after auxiliary_device_init(), the release path can otherwise dereference or clear partially initialized state. Allocate and attach the bnxt_en_dev and ULP table before calling auxiliary_device_init(), so the release callback only sees a fully initialized auxiliary private object. If auxiliary_device_init() itself fails, free those allocations directly because device_initialize() has not run and the release callback will not be invoked. 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-68382", "url": "https://ubuntu.com/security/CVE-2026-68382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Hold device ref until queue teardown completes GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock. Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending. Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work. With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. Replace the fini wait with an assertion and remove the unused fini_wq. v2: - Rebase v3: - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt) - Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt) - Drop separate deferred drm_dev_put worker. - Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini(). v4: - Replace the guc_submit_sw_fini() wait with an assertion and remove the now-unused fini_wq. (sashiko) v5: - Move destroy work to a module-lifetime Xe workqueue instead of system_dfl_wq. (Matt) - Flush the module-lifetime destroy workqueue during PCI remove to preserve the old device-remove wait semantics. v6: - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid letting it outlive the xe_device/drm_device. (Sashiko) - Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work can be queued from the reclaim path. v7: - Drop the per-device xe->destroy_wq and use the module-level destroy WQ for SVM pagemap destroy as well. (Matt) - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*() helpers because the WQ is no longer exec-queue specific. (Matt) v8: - Rebase. v9: - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM destroy_wq because it can be queued from reclaim and embeds the dev_pagemap used by devres teardown. (Sashiko) - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM from it. - Update the module-WQ kdoc to document the GuC/SVM split. v10: - Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the workqueue allocation warning. v11: - Drop the SVM pagemap destroy comment as it was revision-specific. (Thomas) v12: - Rebase. (cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68383", "url": "https://ubuntu.com/security/CVE-2026-68383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Keep scheduler timeline name alive The scheduler keeps a pointer to the timeline name, but q->name is freed with the exec queue while scheduler fences can still reference it. Store the name in struct xe_guc_exec_queue so it shares the scheduler's RCU-deferred lifetime. (cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68390", "url": "https://ubuntu.com/security/CVE-2026-68390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups hci_conn_params_lookup requires hdev->lock be held, otherwise the list iteration or param access is not safe. Hold hdev->lock for params lookups in hci_sync.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-2026-68404", "url": "https://ubuntu.com/security/CVE-2026-68404", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: use wiphy work for socket owner autodisconnect nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68367", "url": "https://ubuntu.com/security/CVE-2026-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: synchronize delayed set_alt with teardown The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68095", "url": "https://ubuntu.com/security/CVE-2026-68095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse-uring: fix race between registration and connection abortion This fixes this race: - thread a: io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref yet - thread b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() is a no-op due to queue ref being 0 - thread a: grabs the queue_ref, queue_ref is now 1, rest of fuse_uring_do_register() logic executes - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs and calls \"wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);\" The abort/unmount thread will hang indefinitely in unkillable state as nothing will decrement queue_refs or wake stop_waitq, and the ring, queue, and ent are leaked. Fix this by checking fch->connected under fch->lock after the created ent has grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either release the queue ref and wake up stop_waitq (in case fuse_chan_wait_aborted() is already waiting) in fuse_uring_do_register() when we detect !fch->connected, or if the connection is aborted after the check, it is guaranteed that the async teardown worker will be running in the background cleaning up ents and decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-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-68173", "url": "https://ubuntu.com/security/CVE-2026-68173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: wait on ublk_dev_ready() instead of ub->completion ub->completion is only re-armed by a successful START_USER_RECOVERY. If the ublk server sends END_USER_RECOVERY without one - e.g. its START failed with -EBUSY and the error was ignored - the wait is satisfied by the stale completion of the previous recovery cycle, and the device is marked LIVE and the requeue list kicked while the FETCH stream is still running and ubq->canceling is still set. The kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it again via __ublk_abort_rq(), and after the last FETCH clears ->canceling nothing ever kicks the requeue list again: the request is stranded there while holding its tag. If it is the flush machinery's flush_rq, every subsequent fsync piles up in uninterruptible sleep and teardown hangs on tag draining. This matches a report of a lost PREFLUSH with ext4 on top of ublk after daemon crash recovery. ub->completion is an edge-triggered latch used as a proxy for the level condition \"every queue has fetched all I/O commands\", which can regress (F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop it and wait on the real condition instead: the new helper ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then re-checks it under ub->mutex, waiting again on regression, and returns with the mutex held and readiness guaranteed. Readiness becomes true in the same ub->mutex critical section that clears the last queue's ->canceling, so END_USER_RECOVERY marks the device LIVE and kicks the requeue list strictly after ->canceling clears. The wait stays interruptible, so a server whose daemon died can still be signalled out. For ublk_ctrl_start_dev() this replaces the fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting until the device is ready again.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68113", "url": "https://ubuntu.com/security/CVE-2026-68113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68118", "url": "https://ubuntu.com/security/CVE-2026-68118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: challenge ACK for non-exact RST in SYN-RECEIVED The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68120", "url": "https://ubuntu.com/security/CVE-2026-68120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtase: Workaround for TX hang caused by hardware packet parsing The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission.", "cve_priority": "medium", "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-68122", "url": "https://ubuntu.com/security/CVE-2026-68122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix peer refcount leak in TCP error paths When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&peer->tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object. The race window: CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error): ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2 schedule_work() <- queued schedule_work() <- NO-OP (work already pending) ovpn_tcp_peer_del_work runs: ovpn_peer_del() ovpn_peer_put() <- refcnt+1 <- peer never freed Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68128", "url": "https://ubuntu.com/security/CVE-2026-68128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: reject out-of-range ptype in ice_parser_profile_init set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from providing ptype >= 1024 through VIRTCHNL, resulting in a write past the end of the bitmap and a kernel page fault. Reproduced with a custom kernel module injecting a crafted VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1. crash_parser: ice_parser_profile_init @ ffffffffc0d61b60 crash_parser: setting ptype=0xffff (max valid=1023) crash_parser: calling ice_parser_profile_init -- expect OOB crash! BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace: ? __pfx_ice_parser_profile_init+0x10/0x10 [ice] crash_init+0x127/0xff0 [crash_parser] do_one_initcall+0x45/0x310 do_init_module+0x64/0x270 init_module_from_file+0xcc/0xf0 idempotent_init_module+0x17b/0x280 __x64_sys_finit_module+0x6e/0xe0 Bail out early with -EINVAL when ptype is out of range.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68132", "url": "https://ubuntu.com/security/CVE-2026-68132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: super: fix emergency thaw deadlock on frozen block devices do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68133", "url": "https://ubuntu.com/security/CVE-2026-68133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP Call Trace during PTP release If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will result in the following PTP release call trace during driver unload: kernel BUG at lib/list_debug.c:52! ice_ptp_release+0x332/0x3c0 [ice] ice_deinit_features.part.0+0x10e/0x120 [ice] ice_remove+0x100/0x220 [ice] This was observed when passing PF1 through to a VM. ice_ptp_init() fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT. Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and returning without error, preventing the invalid state transition to ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from ICE_PTP_RESETTING after a failed rebuild.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68134", "url": "https://ubuntu.com/security/CVE-2026-68134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: ptp_s390: Add missing facility check Only register the physical clock when facility 28 is installed and PTFF QAF returns that PTFF QPT is available.", "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-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-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-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-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-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-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-68150", "url": "https://ubuntu.com/security/CVE-2026-68150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/super: fix emergency thaw double-unlock of s_umount do_thaw_all() iterates over all superblocks via __iterate_supers() with SUPER_ITER_EXCL, which acquires s_umount exclusively before calling the callback and releases it afterwards. However, the callback do_thaw_all_callback() calls thaw_super_locked() which unconditionally releases s_umount on every code path. This results in a second unlock attempt in __iterate_supers() that corrupts the rwsem state, triggering a DEBUG_RWSEMS warning: [ 182.601148] sysrq: Emergency Thaw of all frozen filesystems [ 182.601865] ------------[ cut here ]------------ [ 182.602375] DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff99b1011e5870, owner = 0x0, curr 0xffff99b101b06c80, list not empty [ 182.603817] WARNING: kernel/locking/rwsem.c:1412 at up_write+0xa3/0x170, CPU#2: kworker/2:1/53 [ 182.604578] Modules linked in: [ 182.604864] CPU: 2 UID: 0 PID: 53 Comm: kworker/2:1 Not tainted 7.2.0-rc4-00001-gbd3bd93ea98a-dirty #4 PREEMPT(lazy) [ 182.605711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014 [ 182.606417] Workqueue: events do_thaw_all [ 182.606750] RIP: 0010:up_write+0xaf/0x170 [ 182.607076] Code: 19 3a 92 48 0f 44 c2 48 8b 55 08 48 8b 55 00 4c 8b 45 08 48 8b 55 00 48 8d 3d ad 91 e0 01 48 8b 4d 20 50 48 c7 c6 f0 8c 26 92 <67> 48 0f b9 3a e8 d7 93 4e 00 58 eb 81 48 83 7f 18 00 48 c7 c2 8d [ 182.608563] RSP: 0018:ffffb670001d7e08 EFLAGS: 00010246 [ 182.609007] RAX: ffffffff92349e8d RBX: 0000000000000000 RCX: ffff99b1011e5870 [ 182.609595] RDX: 0000000000000000 RSI: ffffffff92268cf0 RDI: ffffffff92914d10 [ 182.610283] RBP: ffff99b1011e5870 R08: 0000000000000000 R09: ffff99b101b06c80 [ 182.610847] R10: ffff99b10139a808 R11: fefefefefefefeff R12: 0000000000000000 [ 182.611414] R13: ffffffff90cf74d0 R14: 0000000000000000 R15: ffff99b1011e5800 [ 182.612009] FS: 0000000000000000(0000) GS:ffff99b1eaaee000(0000) knlGS:0000000000000000 [ 182.612670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 182.613146] CR2: 00000000005c631c CR3: 00000000013ee000 CR4: 00000000000006f0 [ 182.613722] Call Trace: [ 182.613946] [ 182.614130] __iterate_supers+0x128/0x150 [ 182.614463] do_thaw_all+0x1b/0x30 [ 182.614759] process_scheduled_works+0xbb/0x3f0 [ 182.615150] ? __pfx_worker_thread+0x10/0x10 [ 182.615499] worker_thread+0x129/0x270 [ 182.615816] ? __pfx_worker_thread+0x10/0x10 [ 182.616201] kthread+0xe2/0x120 [ 182.616469] ? __pfx_kthread+0x10/0x10 [ 182.616792] ret_from_fork+0x15b/0x240 [ 182.617115] ? __pfx_kthread+0x10/0x10 [ 182.617426] ret_from_fork_asm+0x1a/0x30 [ 182.617761] [ 182.617968] ---[ end trace 0000000000000000 ]--- [ 182.618412] Emergency Thaw complete Fix this by switching to SUPER_ITER_UNLOCKED and acquiring s_umount in the callback via super_lock_excl() before calling thaw_super_locked(). This matches the locking pattern expected by thaw_super_locked() and eliminates the double unlock. While at it, remove the dead 'return;' at the end of do_thaw_all_callback().", "cve_priority": "low", "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-68152", "url": "https://ubuntu.com/security/CVE-2026-68152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: fix use-after-free in AMT delayed works When an AMT device is removed, pending delayed works can still access the freed amt_dev structure, which may result in kernel crashes or memory corruption. amt_dev_stop() cancels req_wq and discovery_wq with cancel_delayed_work_sync(), but these works can be scheduled again from event_wq after the cancellation. This allows delayed works to access the freed amt_dev structure after the netdev has been released. The following is a simple race scenario: CPU0 CPU1 amt_dev_stop() cancel_delayed_work_sync() amt_event_work() mod_delayed_work(req_wq) free netdev req_wq accesses freed amt_dev Use disable_delayed_work_sync() in amt_dev_stop() to prevent req_wq and discovery_wq from being queued again and wait for running work items to complete. The delayed works are disabled after initialization in amt_newlink() and enabled only when the device is successfully opened. This keeps the delayed work lifecycle synchronized with the lifetime of the AMT device.", "cve_priority": "high", "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-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-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-68168", "url": "https://ubuntu.com/security/CVE-2026-68168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix afs_edit_dir_remove() to get, not find, block 0 Fix afs_edit_dir_remove() to use afs_dir_get_block() to get block 0 rather than afs_dir_find_block() as the latter caches the found block in the afs_dir_iter and may[*] switch out the page it's on if another afs_dir_find_block() is done. This parallels what afs_edit_dir_add() does. [*] There's more than one block per page.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68169", "url": "https://ubuntu.com/security/CVE-2026-68169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: userspace: fix use-after-free in get_local_id In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a \"not found\" sentinel.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68172", "url": "https://ubuntu.com/security/CVE-2026-68172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: make huge_ptep_get handled unaligned addresses huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma). The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned. On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map or into a hole, dereference a VA not mapped into the kernel pgtables and cause kernel panic. Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68174", "url": "https://ubuntu.com/security/CVE-2026-68174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix union collision of module and refcnt for dynamic events In 'struct trace_event_call', the 'module' pointer and the 'refcnt' atomic variable share the same memory space in a union. For dynamic events, the union member is 'refcnt', which acts as an active reference counter. When a dynamic event (such as kprobe, uprobe, fprobe, eprobe, or wprobe) has a non-zero reference count (e.g. due to active event triggers or perf attachments), its 'call->module' evaluates to a small non-zero integer instead of NULL. When filtering or setting events for a specific module (e.g., writing ':mod:' to 'set_event'), the code in '__ftrace_set_clr_event_nolock()' and 'update_event_fields()' reads 'call->module' directly without checking whether the event is dynamic. This causes the kernel to treat the small integer (refcnt) as a 'struct module' pointer, leading to a NULL/invalid pointer dereference (Oops) when dereferencing the module name. Fix this by ensuring that the 'TRACE_EVENT_FL_DYNAMIC' flag is checked before treating 'call->module' as a valid pointer in these code paths.", "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-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-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-68434", "url": "https://ubuntu.com/security/CVE-2026-68434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms Commit b1b4efea05a5 (\"serial: 8250_mid: Disable DMA for selected platforms\") replaced the dnv_board setup and exit callbacks with PTR_IF(false, ...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. Fix this by adding the missing NULL checks before calling the setup and exit callbacks.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17: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-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-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16: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-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-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-68198", "url": "https://ubuntu.com/security/CVE-2026-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix use-after-free in aggr_reset_state() The aggr_reset_state() function uses timer_delete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggr_module_destroy(). If the timer callback (aggr_timeout) is executing when aggr_reset_state() is called, the callback will continue to access aggr_conn fields like rx_tid[] and stat[] which may be freed immediately after by kfree(aggr_info->aggr_conn) in aggr_module_destroy(). Additionally, the timer callback can re-arm itself via mod_timer() while aggr_reset_state() is running, creating a more complex race condition. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "high", "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-68200", "url": "https://ubuntu.com/security/CVE-2026-68200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: don't re-enter an instance callback that is still running The userspace-driven timer (utimer) TRIGGER ioctl calls snd_timer_interrupt() directly with no serialization, so two threads triggering the same utimer can run snd_timer_interrupt() on one snd_timer concurrently. snd_timer_process_callbacks() drops timer->lock around each instance callback and marks the in-flight callback with the single SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that bit to drain an in-flight callback before freeing the instance. The bit cannot represent two concurrent callbacks: when a second interrupt re-queues an instance whose callback is still running, both run at once, the first to finish clears the bit, and the close-path drain then frees the instance (and its callback_data) while the other callback is still live - a use-after-free reachable by any user able to open /dev/snd/timer, both via a user timer instance and via a sequencer queue timer bound to the utimer. snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so a concurrent interrupt already observes it under the lock. Skip re-queuing an instance (and its slaves) to the ack/sack list while its callback is in flight; the accumulated pticks are delivered on the next tick, so no event is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68201", "url": "https://ubuntu.com/security/CVE-2026-68201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: drain a slave's callback before its master detaches it snd_timer_close_locked() drains the closing instance's own in-flight callback (IFLG_CALLBACK) before freeing it, but not its slaves'. When a master instance is closed, remove_slave_links() clears each slave's ->timer; the slave's own close then reads timer == NULL and takes the branch that skips the drain entirely (snd_timer_stop_slave() also no-ops on a NULL timer). So a slave whose callback is still running when the master is closed is freed underneath the live callback, leading to use-after-free. Drain the slaves too before remove_slave_links() severs them. snd_timer_stop() has already taken this instance off the active list, so no new slave callback can be queued. Take the slaves off the ack list so a pending one can't fire either, then wait for any that is already in flight.", "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-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-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-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-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-68211", "url": "https://ubuntu.com/security/CVE-2026-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32-dcmipp: 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. dcmipp_bytecap_start_streaming() returned -EINVAL when the source subdevice could not be resolved from the media graph, before pm_runtime_resume_and_get() and media_pipeline_start() had been called. The remaining error paths already converge on the err_buffer_done label, which calls dcmipp_bytecap_all_buffers_done(..., VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate err_pm_put / err_media_pipeline_stop 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": "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-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-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-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-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-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-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-68230", "url": "https://ubuntu.com/security/CVE-2026-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: amlogic-c3: Add validations for ae and awb config Avoid invalid memory access if the zones_num is bigger than zone_weight. This patch fixes the following smatch errors: drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max", "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-68232", "url": "https://ubuntu.com/security/CVE-2026-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path.", "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-68233", "url": "https://ubuntu.com/security/CVE-2026-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Shut down BO cache timer before teardown The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20: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-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-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-68238", "url": "https://ubuntu.com/security/CVE-2026-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Release VFCT ACPI table reference amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68239", "url": "https://ubuntu.com/security/CVE-2026-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Account for NULL and handle pages in ttm_pool_backup Pages in ttm_pool_backup can be NULL or backup handles (ttm_backup_page_ptr_is_handle()), neither of which can be passed to set_pages_array_wb() or freed. Add a dedicated WB pass before the dma/purge loop that walks allocations using the same i += num_pages stride, skipping NULL and handle entries, and calls set_pages_array_wb() once per contiguous run of real pages. Apply the same NULL/handle guard to the dma/purge loop. Fixes the following oops: Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI RIP: 0010:__cpa_process_fault+0xf8/0x770 RSP: 0018:ffffc90000a87718 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34 RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0 R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000 R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0 FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0 PKRU: 55555554 Call Trace: __change_page_attr_set_clr+0x989/0xe90 ? __purge_vmap_area_lazy+0x6c/0x3a0 ? _vm_unmap_aliases+0x250/0x2a0 set_pages_array_wb+0x7f/0x120 ttm_pool_backup+0x4c9/0x5b0 [ttm] ? dma_resv_wait_timeout+0x3b/0xf0 ttm_tt_backup+0x32/0x60 [ttm] ttm_bo_shrink+0x66/0x110 [ttm] xe_bo_shrink_purge+0x12b/0x1b0 [xe] xe_bo_shrink+0xbb/0x270 [xe] __xe_shrinker_walk+0xf7/0x160 [xe] xe_shrinker_walk+0x9d/0xc0 [xe] xe_shrinker_scan+0x11f/0x210 [xe] do_shrink_slab+0x13b/0x270 shrink_slab+0xf1/0x400 shrink_node+0x352/0x8a0 balance_pgdat+0x32c/0x700 kswapd+0x205/0x2f0 ? __pfx_autoremove_wake_function+0x10/0x10 ? __pfx_kswapd+0x10/0x10 kthread+0xd1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1b1/0x200 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68241", "url": "https://ubuntu.com/security/CVE-2026-68241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/mst: limit DP MST ESI service loop The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto. (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)", "cve_priority": "medium", "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-68245", "url": "https://ubuntu.com/security/CVE-2026-68245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only valid while the lock is still being held. Once xa_unlock_irqrestore is called and returned, the pointer is no longer under lock and is subject to modification. Since, the caller still dereferences vm->task_info in amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a use after unlock problem. Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid() through removing the amdgpu_vm_get_vm_from_pasid() function from amdgpu_vm.c and making the relevant code inline to hold the lock while it is still in use. (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)", "cve_priority": "high", "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-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-68252", "url": "https://ubuntu.com/security/CVE-2026-68252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68253", "url": "https://ubuntu.com/security/CVE-2026-68253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)", "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-68257", "url": "https://ubuntu.com/security/CVE-2026-68257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix 32-bit overflow in CWSR total size calculation total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68258", "url": "https://ubuntu.com/security/CVE-2026-68258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on CRIU restore queue type and mqd size We weren't checking whether the values provided in the private data in kfd CRIU restore were within bounds. For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it. For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations. (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)", "cve_priority": "low", "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-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-68266", "url": "https://ubuntu.com/security/CVE-2026-68266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68268", "url": "https://ubuntu.com/security/CVE-2026-68268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Return error on non-migratable faults requiring devmem Non-migratable faults that require devmem incorrectly jump to the 'out' label, which squashes the error code intended to be returned to the upper layers. Fix this by returning -EACCES instead. (cherry picked from commit c4508edb2c723de93717272488ea65b165637eac)", "cve_priority": "medium", "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-68270", "url": "https://ubuntu.com/security/CVE-2026-68270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Avoid possible truncation with calculating visible size Calculating the visible size of the system framebuffer can result in truncation of the result. The calculation uses 32-bit arithmetics, which can overflow if the values for height and stride are large. Fix the issue by multiplying with mul_u32_u32().", "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-68275", "url": "https://ubuntu.com/security/CVE-2026-68275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks up the bo_va for the buffer object in the caller's VM via amdgpu_vm_bo_find(), but uses the returned pointer without checking it. amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM, which is the normal case for a BO that has never been mapped. The result is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which expands to list_for_each_entry(mapping, &(bo_va)->valids, list) and dereferences bo_va, causing a NULL pointer dereference. This is reachable by any process able to issue the ioctl (render group) simply by requesting mapping info for an unmapped BO. Return -ENOENT when no bo_va is found, jumping to out_exec so the drm_exec context and GEM object reference are released. (cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68276", "url": "https://ubuntu.com/security/CVE-2026-68276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx: fix cleaner shader IB buffer overflow The cleaner shader sysfs path allocates a 16-dword (64 byte) IB but incorrectly fills (align_mask + 1) dwords. On GFX rings align_mask is 0xff, so the loop wrote 256 dwords into a 64-byte buffer, causing a kernel page fault. The IB only needs to be a minimal NOP shell to schedule the job; the cleaner shader itself is emitted on the ring via emit_cleaner_shader(). Fill 16 dwords to match the allocation. v2: Use ib_size_dw variable (Lijo) (cherry picked from commit bf21af331ebf72d0935fd70c73192414a422c03a)", "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-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-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-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-68282", "url": "https://ubuntu.com/security/CVE-2026-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: analogix_dp: Add missing error check for platform_get_resource() Add missing error check for platform_get_resource() return value to prevent NULL pointer dereference when memory resource is not available.", "cve_priority": "medium", "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-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-68292", "url": "https://ubuntu.com/security/CVE-2026-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues.", "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-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-68296", "url": "https://ubuntu.com/security/CVE-2026-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM Before commit 00d066a4d4ed (\"netdev_features: convert NETIF_F_LLTX to dev->lltx\"), NETIF_F_LLTX was set unconditionally in both __gre_tunnel_init() and ip6gre_tnl_init_features() alongside GRE_FEATURES: dev->features |= GRE_FEATURES | NETIF_F_LLTX; When that commit converted NETIF_F_LLTX to the dev->lltx flag, it placed 'dev->lltx = true' after the SEQ/CSUM early returns instead of before them. This causes GRE/GRETAP/ip6gre tunnels with SEQ or CSUM+encap to lose lockless TX, reintroducing _xmit_lock acquisition around their ndo_start_xmit. Since GRE xmit re-enters the stack via ip_tunnel_xmit(), holding _xmit_lock risks ABBA deadlock with the underlay device. CPU0 CPU1 ---- ---- lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); Fix by moving dev->lltx = true before the early returns in both functions, restoring the original unconditional behavior.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64575", "url": "https://ubuntu.com/security/CVE-2026-64575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: fix double sock release on batch realloc bpf_iter_tcp_batch() releases the current batch via bpf_iter_tcp_put_batch(), which drops the socket refs and rewrites each slot with the socket cookie, then grows the batch. cur_sk/end_sk are kept for bpf_iter_tcp_resume(), but on realloc failure the function returns ERR_PTR() before resume runs, leaving cur_sk < end_sk over slots that now hold cookies rather than sock pointers. bpf_iter_tcp_seq_stop() then calls bpf_iter_tcp_put_batch() again and dereferences a cookie as a struct sock. Empty the batch on the failure path so stop() does not release it again. The sockets were already freed by the first bpf_iter_tcp_put_batch(), so nothing leaks, and a later read() rescans the bucket from the start instead of skipping it. The sibling GFP_NOWAIT failure path still holds real socket references and is left for stop() to release. BUG: KASAN: null-ptr-deref in __sock_gen_cookie Read of size 8 at addr 0000000000000059 by task exploit ... __sock_gen_cookie (net/core/sock_diag.c:28) bpf_iter_tcp_put_batch (net/ipv4/tcp_ipv4.c:2918) bpf_iter_tcp_seq_stop (net/ipv4/tcp_ipv4.c:3270) bpf_seq_read (kernel/bpf/bpf_iter.c:205) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 entry_SYSCALL_64_after_hwframe Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68298", "url": "https://ubuntu.com/security/CVE-2026-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create() Commit 9e9787414882 (\"drm/xe/userptr: replace xe_hmm with gpusvm\") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a \"simple\" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). (cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4)", "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-68448", "url": "https://ubuntu.com/security/CVE-2026-68448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: check access to copy_file_range source with src mounter creds Commit 5dae222a5ff0c (\"vfs: allow copy_file_range to copy across devices\") allowed filesystems that implement the copy_file_range() f_op to decide if they want to access cross-sb copy from/to the same fs type. The same commit added checks to verify same sb copy for filesystems that implement ->copy_file_range() and do not support cross-sb copy at the time, namely, to ceph, fuse and nfs. The two remaining fs which implement ->copy_file_range(), cifs and overlayfs started to support cross-sb copy from this time. While overlayfs does support cross-sb copy when the two underlying files are on the same base fs, the copy operation on the two real files from two different overalyfs filesystems is performed with the mounter creds of the destination overlayfs and the read permission access hook for the source file was called with the wrong creds. This could cause either deny of access to copy which would otherwise be allowed (e.g. with splice) or allow read access to file which would otherwise be denied. Fix the latter case by explicitly verifying read access to source file with the source overlayfs mounter creds. The former case remains a quirk of cross-sb overlayfs copy, but userspace could fall back to regular copy so no harm done.", "cve_priority": "low", "cve_public_date": "2026-08-12 01:17: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-68307", "url": "https://ubuntu.com/security/CVE-2026-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix crash in reset link replay During reset recovery, mt7925_vif_connect_iter() replays firmware state for links tracked in mvif->valid_links. After MLO link changes or MCU timeout recovery, the driver bitmap can temporarily contain a link whose mac80211 bss_conf has already gone away. This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching the crash where x1, the second argument, is NULL: pc : mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] lr : mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] x2 : ffffff80a77f6018 x1 : 0000000000000000 x0 : ffffff8099402080 Call trace: mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common] Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA reset replay is unchanged because the helper still returns &vif->bss_conf for the legacy link.", "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-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-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-68311", "url": "https://ubuntu.com/security/CVE-2026-68311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: guard link STA in decap offload mt7925_sta_set_decap_offload() iterates over the vif valid_links mask when updating decap offload state for an MLO station. The station may not have a link STA for every valid link of the vif, so mt792x_sta_to_link() can return NULL for a link that belongs to the vif but not to the station. The function currently dereferences mlink before checking whether the link WCID is ready. If mlink is NULL, setting or clearing MT_WCID_FLAG_HDR_TRANS dereferences a NULL pointer. Skip links without a station link before touching mlink->wcid.", "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-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-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-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-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-68321", "url": "https://ubuntu.com/security/CVE-2026-68321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix FDIR filter leak on remove Perfect FDIR filters can be added while the interface is down and are kept on the software list for later restore. unregister_netdev() only calls ndo_stop when the device is up, so txgbe_fdir_filter_exit() in txgbe_close() is skipped in that case and the filters are leaked on driver remove. Free the filter list from txgbe_remove() as well.", "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-68330", "url": "https://ubuntu.com/security/CVE-2026-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix DMA direction for NPU mailbox buffer airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE, but some callers expect the NPU to write response data back into the same buffer: - airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into the buffer, then the caller reads it via memcpy() - airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back npu_stats_addr field in the response On non-cache-coherent architectures like EN7581 (Cortex-A53 without hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op — it does not invalidate the CPU cache. If the NPU-written cache line is still present in the CPU cache when the caller reads the buffer, the CPU observes stale data instead of the NPU response. This is a timing-sensitive bug: small mailbox buffers (~24 bytes) typically fit in a single cache line and may survive in the cache until the caller reads them, producing silent data corruption rather than a crash. The bug is more likely to trigger when the caller reads the response immediately after dma_unmap_single() without intervening cache-evicting operations. Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures dma_unmap_single() invalidates the CPU cache on non-coherent systems. The mailbox buffers are small so there is no performance concern.", "cve_priority": "low", "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-68332", "url": "https://ubuntu.com/security/CVE-2026-68332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix potential use-after-free in airoha_ppe_deinit() airoha_ppe_deinit() replaces the NPU pointer with NULL via rcu_replace_pointer() but does not wait for existing RCU readers to exit before calling ppe_deinit() and airoha_npu_put(). This can cause a use-after-free if a reader in an RCU read-side critical section still holds a reference to the NPU when it is freed. The init path (airoha_ppe_init) already calls synchronize_rcu() after rcu_assign_pointer(), but the deinit path introduced in commit 6abcf751bc08 (\"net: airoha: Fix schedule while atomic in airoha_ppe_deinit()\") omitted the matching barrier when switching from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer(). Add synchronize_rcu() before ppe_deinit() to ensure all existing RCU readers have completed before the NPU resources are released.", "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-68334", "url": "https://ubuntu.com/security/CVE-2026-68334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix io_thread race in rxrpc_wake_up_io_thread() rxrpc_wake_up_io_thread() checks local->io_thread before waking it, but then reloads the pointer for wake_up_process(). local->io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so the second load can see NULL even if the first load did not. Take a READ_ONCE() snapshot and use it for both the NULL check and the wake_up_process() call, as rxrpc_encap_rcv() already does.", "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-68341", "url": "https://ubuntu.com/security/CVE-2026-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix use after free in unlock_ovpn() unlock_ovpn() iterates over the release_list using llist_for_each_entry() and drops the peer reference inside the loop body via ovpn_peer_put(). If this drops the last reference, the peer is eventually freed. However, llist_for_each_entry() reads peer->release_entry.next in the loop advance expression, which runs after the body. By that time the peer may have already been freed, resulting in a use after free when advancing to the next list entry. Fix this by using llist_for_each_entry_safe(), which caches the next pointer before executing the loop body.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68342", "url": "https://ubuntu.com/security/CVE-2026-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: avoid putting unrelated P2P peer on socket release ovpn_peer_release_p2p() is called when an OVPN UDP socket is being destroyed. It checks the currently published P2P peer and releases it only if that peer still uses the socket being destroyed. A peer replacement can publish a new peer before the old UDP socket is destroyed. When the old socket destruction path runs afterwards, ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the new peer uses a different socket, the function takes the socket mismatch branch. That branch still calls ovpn_peer_put(peer). At this point, however, peer is the currently published replacement peer, not the peer associated with the socket being destroyed. Dropping its reference can free it while ovpn->peer still points to it, leading to later use-after-free accesses from the peer and socket cleanup paths. KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer object. In the reproducer, the object is allocated from ovpn_peer_new() via ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU callback processing. Observed access sites include ovpn_peer_remove(), ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn(). Fix this by returning from the socket mismatch branch without putting the peer.", "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-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-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-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-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-68356", "url": "https://ubuntu.com/security/CVE-2026-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: airoha: Prevent division by zero when clock frequency is zero clk_get_rate() can return 0 when the clock provider is not properly configured or the clock is unmanaged. The driver uses wdt_freq as a divisor directly in airoha_wdt_probe() to compute max_timeout and in airoha_wdt_get_timeleft() to compute the remaining time, which results in a division by zero. Add a check for wdt_freq == 0 in probe and return -EINVAL with dev_err_probe() to prevent the division by zero and provide a diagnostic message.", "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-68358", "url": "https://ubuntu.com/security/CVE-2026-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-kraken3) 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-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-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-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-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-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-68374", "url": "https://ubuntu.com/security/CVE-2026-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: sysfs: add lock to bos_descriptors_read() Add a lock to the function bos_descriptors_read(). This function accesses udev->bos, which could be simultaneously freed in usb_reset_and_verify_device(), a function that is commonly called in drivers all over the kernel.", "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-68378", "url": "https://ubuntu.com/security/CVE-2026-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions: - A pin is registered with two or more dpll devices (dpll_A, dpll_B) - The pin has ref_sync pairs with other pins - During unregistration of dpll_A's pins, a ref_sync partner pin is unregistered first, removing it from dpll_A->pin_refs - But since the partner pin is still registered with dpll_B, its dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT run and the partner stays in the pin's ref_sync_pins xarray - When the pin itself is then unregistered from dpll_A, the delete notification calls dpll_msg_add_pin_ref_sync() which finds the partner in ref_sync_pins, passes dpll_pin_available() (partner is still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A, partner) returns NULL because partner was already removed from dpll_A->pin_refs - The NULL priv pointer is passed to the driver's ref_sync_get callback, which dereferences it BUG: kernel NULL pointer dereference, address: 0000000000000034 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x] Call Trace: dpll_msg_add_pin_ref_sync+0xb8/0x200 dpll_cmd_pin_get_one+0x3b6/0x4b0 dpll_pin_event_send+0x72/0x140 __dpll_pin_unregister+0x5a/0x2b0 dpll_pin_unregister+0x49/0x70 Fix this by skipping ref_sync pins whose priv pointer cannot be resolved for the current dpll device.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68379", "url": "https://ubuntu.com/security/CVE-2026-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix TIME_WAIT socket reference leak on PSP policy failure Release the TIME_WAIT socket reference and jump to discard_it upon PSP policy failure in both IPv4 and IPv6 receive paths. This prevents a memory leak of tcp_tw_bucket structures.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68380", "url": "https://ubuntu.com/security/CVE-2026-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix use-after-free of mm_struct in job scheduler amdxdna_cmd_submit() stores current->mm in job->mm without holding any reference. aie2_sched_job_run() later access job->mm from the DRM scheduler worker thread. With only a raw pointer and no structural reference, the mm_struct can be freed before the scheduler runs the job. Fix this by calling mmgrab() to hold a structural mm_count reference for the lifetime of the job, paired with mmdrop() in every cleanup path.", "cve_priority": "high", "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-68384", "url": "https://ubuntu.com/security/CVE-2026-68384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits. - Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it. While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one. (cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68385", "url": "https://ubuntu.com/security/CVE-2026-68385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/checksum: Fix csum_partial() without vector facility Currently csum_partial() calls csum_copy() with copy=false and dst=NULL. On machines without the vector facility, csum_copy() falls back to cksm(dst, ...), causing the checksum to be calculated from address zero instead of the source buffer. The VX implementation already checksums data loaded from src. Make the fallback do the same by passing src to cksm().", "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-68387", "url": "https://ubuntu.com/security/CVE-2026-68387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: add locking for raw flags bitfield With commit 890e5198a6e5 (\"can: raw: use bitfields to store flags in struct raw_sock\") the formerly separate integer values have been integrated into a single bitfield. This led to a read-modify-write operation when changing a flag in raw_setsockopt() which now needs a locking to prevent concurrent access. Instead of adding a lock/unlock hell in each of the flag manipulations this patch introduces a wrapper for a new raw_setsockopt_locked() function analogue to the isotp_setsockopt[_locked]() approach in net/can/isotp.c [mkl: use Closes tag instead of Link]", "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-68393", "url": "https://ubuntu.com/security/CVE-2026-68393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: extend conn_hash lookup critical sections Using RCU-protected pointers outside the critical sections without refcount is incorrect and may result to UAF. Extend critical section to cover both hci_conn_hash lookup and use of the returned conn. Add surrounding rcu_read_lock() also when return value is not used, in preparation for RCU lockdep requirement to hci_lookup_le_connect(). This avoids concurrent deletion of the conn before we are done dereferencing it. Also, make sure to hold hdev->lock when accessing hdev->accept_list.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68394", "url": "https://ubuntu.com/security/CVE-2026-68394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update MGMT_OP_LOAD_CONN_PARAM queues conn_update_sync() when a single parameter update changes an existing LE central connection. The queued work currently stores a borrowed hci_conn_params entry from hdev->le_conn_params. A later LOAD_CONN_PARAM request can clear disabled parameters and free that entry before hci_cmd_sync_work() runs the queued callback. Do not keep the borrowed hci_conn_params pointer in queued work. Queue the hci_conn instead and hold a reference until the queued callback completes. When the work runs, revalidate that the connection is still present, look up the current hci_conn_params entry, and cancel the update if userspace removed that entry while the work was pending. Copy the interval values from the current params entry under hdev->lock, then drop the lock and keep using hci_le_conn_update_sync() to issue the update. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in conn_update_sync+0x2a/0xf0 [bluetooth] Read of size 1 at addr ffff88810c697126 by task kworker/u17:0/377 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 kasan_report+0xe0/0x110 conn_update_sync+0x2a/0xf0 [bluetooth] hci_cmd_sync_work+0x187/0x210 [bluetooth] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 Allocated by task 466: hci_conn_params_add+0xa6/0x240 [bluetooth] load_conn_param+0x4e1/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] Freed by task 474: kfree+0x313/0x590 hci_conn_params_clear_disabled+0x9b/0xc0 [bluetooth] load_conn_param+0x4bf/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth]", "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-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-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-68400", "url": "https://ubuntu.com/security/CVE-2026-68400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint memory access array and to comply with the FF-A spec instead of defaulting to `sizeof(struct ffa_mem_region)`. This requires moving `ffa_mem_region_additional_setup()` earlier in the setup flow. Also, add sanity checks to ensure the calculated descriptor offsets do not exceed `max_fragsize`.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68401", "url": "https://ubuntu.com/security/CVE-2026-68401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() Sashiko (locally) reports multiple out-of-bound issues in ffa_setup_and_transmit: 1) Writing ep_mem_access->reserved can write out of bounds for FFA versions < 1.2 as ffa_emad_size_get() returns 16 bytes in that case while reserved has an offset of 24. Instead of zeroing fields, memset the struct to zero first based on the FFA version. 2) Make sure there is enough size to write constituents. While at it, convert the only sizeof() in the driver that uses a type instead of variable.", "cve_priority": "high", "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-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-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-68409", "url": "https://ubuntu.com/security/CVE-2026-68409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: defer link RX stats percpu free to RCU sta_remove_link() frees a removed MLO link's RX stats percpu buffer right away, but defers only the link container to RCU: \tsta_info_free_link(&alloc->info); \tkfree_rcu(alloc, rcu_head); The RX fast path reads link_sta under rcu_read_lock and writes the percpu stats. A reader that resolved link_sta before the removal keeps the pointer. The container stays alive from the kfree_rcu, so the read still works. But the percpu block it points to is already freed. This needs uses_rss. That is when pcpu_rx_stats exists. The full STA teardown frees the deflink stats only after synchronize_net(). The link removal path had no such barrier. The race is hard to win in practice, but the free should still wait for RCU. Free the link together with its data from a single RCU callback, so the percpu block is reclaimed only after readers drain.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20: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-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-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-68412", "url": "https://ubuntu.com/security/CVE-2026-68412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan() If the test against IEEE80211_MAX_SSID_LEN fails, then 'creq' leaks. Use the existing error handling path to fix it.", "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-64566", "url": "https://ubuntu.com/security/CVE-2026-64566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags() When iptfs_skb_add_frags() copies frag references from the source frag walk into a new SKB, it increments the page reference count via __skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the destination SKB's skb_shinfo->flags. If the source SKB carries shared frags (e.g. from a page-pool backed receive path), the new inner SKB will appear to ESP as having privately owned frags. A subsequent esp_input() call for a nested transport-mode SA then takes the no-COW fast path and decrypts in place, writing over pages that are still referenced by the outer IPTFS SKB. This causes kernel-visible memory corruption and can trigger a panic. All other frag-transfer helpers in the kernel (skb_try_coalesce, skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this convention by setting the flag inside the loop immediately after __skb_frag_ref() and nr_frags++, so every exit path that attaches a frag unconditionally propagates SKBFL_SHARED_FRAG.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68415", "url": "https://ubuntu.com/security/CVE-2026-68415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear mode callbacks after failed mode setup xfrm_state_gc_task can run long after a failed IPTFS state setup. In the reproduced case, __xfrm_init_state() cached x->mode_cbs, IPTFS setup returned -ENOMEM before publishing mode_data, and the temporary module reference from xfrm_get_mode_cbs() was dropped immediately. The dead state then kept x->mode_cbs until deferred GC ran after xfrm_iptfs had been unloaded. Clear x->mode_cbs when mode init or clone fails before publishing mode_data. Those states never installed mode-specific state or the long-term IPTFS module pin, so deferred GC has nothing mode-specific to destroy and must not retain a callback table pointer past the temporary lookup reference. The buggy scenario involves two paths, with each column showing the order within that path: failed setup path: 1. cache x->mode_cbs 2. mode setup fails before mode_data 3. drop the temporary module ref 4. dead state keeps x->mode_cbs cached GC/unload path: 1. xfrm_state_put() queues GC work 2. xfrm_iptfs unloads later 3. xfrm_state_gc_task runs 4. GC dereferences stale x->mode_cbs This also covers the failed clone path where clone_state() returns before publishing mode_data. Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y failslab_stacktrace_filter matched xfrm_iptfs frames ack_error=-12 FAULT_INJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrm_state_gc_task RIP: xfrm_state_gc_task+0x142/0x650 Modules linked in: esp4_offload xfrm_user [last unloaded: xfrm_iptfs] Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68418", "url": "https://ubuntu.com/security/CVE-2026-68418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent user-triggered null deref on QP create Previously, the user QP creation path would only attempt to populate iwqp->iwpbl if the user-provided req.user_wqe_bufs field was non-zero. The problem is that iwqp->iwpbl is unconditionally dereferenced later on in irdma_setup_virt_qp. While there was a check for iwqp->iwpbl != NULL, this check would only occur if req.user_wqe_bufs was non-zero. The end result is that a user could send a zero user_wqe_bufs value and trigger a null ptr deref. Fix this by unconditionally calling irdma_get_pbl and bailing if it fails, similar to the CQ and SRQ paths.", "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-68420", "url": "https://ubuntu.com/security/CVE-2026-68420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: reject optional IPTFS templates in outbound policies syzbot reported a stack-out-of-bounds read in xfrm_state_find() which flows from xfrm_tmpl_resolve_one(). Commit 3d776e31c841 (\"xfrm: Reject optional tunnel/BEET mode templates in outbound policies\") disallowed optional tunnel and BEET in outbound policies to prevent this. Later when IPTFS added, it was not covered by that fix and can still trigger the out-of-bounds read; Extend the check to disallow optional IPTFS in outbound policies as well. IPTFS should be identical to tunnel mode. IN and FWD policies are not affected: xfrm_tmpl_resolve_one() is only reachable via the outbound path. Reproducer, before: ip link add dummy0 type dummy ip link set dummy0 up ip addr add 10.1.1.1/24 dev dummy0 ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 mode transport ping -W 1 -c 1 10.1.1.2 PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data. [ 64.168420] ================================================================== [ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844 [ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full) [ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 64.169977] Call Trace: [ 64.169977] [ 64.169977] dump_stack_lvl+0x47/0x70 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] print_report+0x152/0x4b0 [ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0 [ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20 [ 64.169977] ? __virt_addr_valid+0x21b/0x230 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] kasan_report+0xa8/0xd0 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm_dst_hash+0x24/0xc0 [ 64.169977] xfrm_state_find+0xa2d/0x2f90 [ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570 [ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10 [ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 64.169977] ? kernel_text_address+0x5b/0x80 [ 64.169977] ? __kernel_text_address+0xe/0x30 [ 64.169977] ? unwind_get_return_address+0x5e/0x90 [ 64.169977] ? arch_stack_walk+0x8c/0xe0 [ 64.169977] xfrm_tmpl_resolve+0x130/0x200 [ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10 [ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110 [ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10 [ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310 [ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80 [ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10 [ 64.169977] ? ip_route_output_key_hash+0xc6/0x110 [ 64.169977] ? kasan_save_track+0x10/0x30 [ 64.169977] xfrm_lookup_route+0x18/0xe0 [ 64.169977] ip4_datagram_release_cb+0x4c9/0x530 [ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10 [ 64.169977] ? do_raw_spin_lock+0x71/0xc0 [ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 64.169977] release_sock+0xb0/0x170 [ 64.169977] udp_connect+0x43/0x50 [ 64.169977] __sys_connect+0xa6/0x100 [ 64.169977] ? alloc_fd+0x2e9/0x300 [ 64.169977] ? __pfx___sys_connect+0x10/0x10 [ 64.169977] ? preempt_latency ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68421", "url": "https://ubuntu.com/security/CVE-2026-68421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx() put_prev_task_scx() warns when a runnable task drops to a lower sched_class without SCX_OPS_ENQ_LAST, on the assumption that balance_one() would have kept it running. Core scheduling breaks that: a forced-idle SMT sibling reschedules through the core_pick fast path in pick_next_task(), which skips pick_task_scx() and thus balance_one(), so a runnable task can drop to idle with ENQ_LAST unset. Gate the warning on sched_cpu_cookie_match(): a cookie mismatch means core scheduling forced the idle, while a match (or core scheduling off) still catches a genuine missing-ENQ_LAST drop.", "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-68426", "url": "https://ubuntu.com/security/CVE-2026-68426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix stale skb->prev after async crypto steals a GSO segment skb_gso_segment() leaves the segment list head with ->prev pointing at the last segment, an invariant validate_xmit_skb_list() relies on when it sets its tail pointer (tail = skb->prev). When validate_xmit_xfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validate_xmit_skb_list() later does tail->next = skb, writing through that stale pointer -- a use-after-free. Repoint skb->prev at the last retained segment before returning.", "cve_priority": "critical", "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-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-2023-20585", "url": "https://ubuntu.com/security/CVE-2023-20585", "cve_description": "Insufficient checks of the RMP on host buffer access in IOMMU may allow an attacker with privileges and a compromised hypervisor to trigger an out of bounds condition without RMP checks, resulting in a potential loss of confidential guest integrity.", "cve_priority": "low", "cve_public_date": "2026-04-16 19:16:00 UTC" }, { "cve": "CVE-2026-68364", "url": "https://ubuntu.com/security/CVE-2026-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix ISM dc_lock deadlock during suspend [Why] System hang observed during suspend/resume while video is playing. amdgpu_dm_ism_disable() is called under dc_lock and waits for ISM delayed work via disable_delayed_work_sync(). The work handlers themselves take dc_lock, producing an ABBA deadlock when a worker is in flight at suspend time. [How] Split the disable path into two phases with opposite locking contracts: 1. amdgpu_dm_ism_disable() -- quiesces workers, must NOT hold dc_lock. 2. amdgpu_dm_ism_force_full_power() (new) -- drives the ISM FSM back to FULL_POWER_RUNNING, must hold dc_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72064", "url": "https://ubuntu.com/security/CVE-2026-72064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Sync page pool RX frags for CPU MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack.", "cve_priority": "medium", "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-72098", "url": "https://ubuntu.com/security/CVE-2026-72098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: fix buffer overflow in FEC calculation There's a buffer overflow in dm-verity-fec: if (neras && *neras <= v->fec->roots) \tfio->erasures[(*neras)++] = i; This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72248", "url": "https://ubuntu.com/security/CVE-2026-72248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: support IPIP tunnel with direct xmit The combination of IPIP tunnel with direct xmit, eg. bridge device, breaks because no dst_entry is provided to check the skb headroom and to set the iph->frag_off field. This leads to invalid dst usage and can trigger a crash in the tunnel transmit path. Fix this by moving dst_cache and dst_cookie out of the runtime union so that they can be shared by neighbour, xfrm, and direct tunnel flows. For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve route state in these shared fields and release it through the common dst release path. Since dst_entry is now available to the three supported xmit modes and dst_release() already deals with NULL dst, remove the xmit type check in nft_flow_dst_release(). Moreover, skip the check if the dst entry is NULL in nf_flow_dst_check() which is now the case for the direct xmit case. Based on patch from Rein Wei .", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72249", "url": "https://ubuntu.com/security/CVE-2026-72249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: use dst in this direction when pushing IPIP header When pushing the IPIP header, the route of the other direction is used to calculate the headroom, use the route in this direction. Accessing the other tuple to set the IP source and destination is fine because this tuple does not provide such information to avoid storing redundant information. However, this tuple already provides the dst for this direction, this went unnoticed because this bug affects headroom and iph->frag_off only at this stage.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72287", "url": "https://ubuntu.com/security/CVE-2026-72287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the \"normal\" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a \"late\" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72329", "url": "https://ubuntu.com/security/CVE-2026-72329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/liquidio: drop cached VF pci_dev LUT The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST. Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72355", "url": "https://ubuntu.com/security/CVE-2026-72355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix barriering when walking subrequest list Fix the barriering used when walking the subrequest list in retry as there's a possibility of seeing a subreq that's just been added by the application thread.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72412", "url": "https://ubuntu.com/security/CVE-2026-72412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/mm: Fix handling of _PAGE_UNUSED pte bit The _PAGE_UNUSED softbit should not really be lying around. Its sole purpose is to signal to try_to_unmap_one() and try_to_migrate_one() that the page can be discarded instead of being moved / swapped. KVM has no way to know why a page is being unmapped, so it sets the bit on userspace ptes corresponding to unused guest pages every time they get unmapped. KVM has no reasonable way to clear the bit once the page is in use again. While set_ptes() checks and clears the bit, other paths that set new ptes did not. This led to used pages being thrown out as if they were unused, causing guest corruption. Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in set_pte(), i.e. whenever a present pte is getting set. The check in set_ptes() is then redundant and can be removed. Also fix gmap_helper_try_set_pte_unused() to only set the bit if the pte is present; the _PAGE_UNUSED bit is only defined for present ptes and thus should not be set for non-present ptes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72417", "url": "https://ubuntu.com/security/CVE-2026-72417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto() Add sanity check for iph->ihl field in nf_flow_ip4_tunnel_proto() before using it to compute the header size, avoiding out-of-bounds access with malformed IP headers. While at it, use iph->protocol instead of the hardcoded IPPROTO_IPIP constant when setting ctx->tun.proto and reference ctx->tun.hdr_size when updating ctx->offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72442", "url": "https://ubuntu.com/security/CVE-2026-72442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: fix and simplify IP6IP6 tunnel handling Fix nf_flow_ip6_tunnel_proto() to use pskb_may_pull() instead of skb_header_pointer() to ensure the outer IPv6 header is in the skb headroom, which is required for subsequent packet processing. Move ctx->offset update inside the IPPROTO_IPV6 conditional block since it should only be adjusted when an IP6IP6 tunnel is actually detected. Simplify the rx path by removing ipv6_skip_exthdr() and checking ip6h->nexthdr directly, as the flowtable fast path only handles simple IP6IP6 encapsulation without extension headers. Drop the tunnel encapsulation limit destination option support from the tx path to match, since the rx path no longer handles extension headers. Remove the encap_limit parameter from nf_flow_offload_ipv6_forward(), nf_flow_tunnel_ip6ip6_push() and nf_flow_tunnel_v6_push(), along with the ipv6_tel_txoption struct and related headroom/MTU adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72463", "url": "https://ubuntu.com/security/CVE-2026-72463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix dev use-after-free in xfrm async resumption xfrm async resumption hold skb->dev refcnt until after transport_finish. However, xfrm_rcv_cb may modify skb->dev to tunnel dev without taking device reference, such as vti_rcv_cb. The subsequent async resumption will decrement the tunnel device's reference count, which lead to uaf of tunnel dev and refcnt leak of orig dev as below: unregister_netdevice: waiting for vti1 to become free. Usage count = -2 Stash the original skb->dev to fix refcnt imbalance. The new skb->dev set by xfrm_rcv_cb can race with device teardown. Extend rcu protection over xfrm_rcv_cb and transport_finish to prevent races.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72477", "url": "https://ubuntu.com/security/CVE-2026-72477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: call _ntfs_bad_inode() when failing to rename It is safe to call _ntfs_bad_inode on live inodes since: commit 519b078998ce (\"fs/ntfs3: Exclude call make_bad_inode for live nodes.\") The WARN_ON was added when it wasn't safe by: commit d99208b91933 (\"fs/ntfs3: cancle set bad inode after removing name fails\") Replace the WARN_ON with a call to _ntfs_bad_inode() to prevent further operations on the inconsistent inode.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72493", "url": "https://ubuntu.com/security/CVE-2026-72493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: serialize netif_running() check in enqueue_to_backlog() Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup(). The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit). Commit e9e4dd3267d0 (\"net: do not process device backlog during unregistration\") introduced a lockless netif_running() check in enqueue_to_backlog() to prevent queuing packets to an unregistering device. However, this creates a TOCTOU race window. A lockless transmitter (like veth_xmit) can pass the check before dev_close() clears IFF_UP. If the transmitter is then delayed, flush_all_backlogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed. Fix this by moving the netif_running() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netif_running() after the flush/close completes (so it gets dropped).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72494", "url": "https://ubuntu.com/security/CVE-2026-72494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Replace waitqueue and flag with completion The driver previously used a waitqueue along with an explicit request_done flag, but without proper barriers around request_done. An earlier patch by Gui-Dong Han attempted to fix this by adding the missing memory barriers. Rather than adding the barriers, this patch replaces the waitqueue+flag with a completion, which is designed for this exact purpose.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72496", "url": "https://ubuntu.com/security/CVE-2026-72496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Proper rollback if the ioremap fails bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74269", "url": "https://ubuntu.com/security/CVE-2026-74269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt: fix head underflow on XDP head-grow The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free. The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with this commit applied causes the test to run successfully to completion. The other rx_skb_func implementations don't have this issue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74350", "url": "https://ubuntu.com/security/CVE-2026-74350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate fast symlink target during inode read ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment. A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer. Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated. This keeps malformed fast symlinks from reaching the read path. Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x19f/0x330 (?:?) kasan_report+0xe0/0x110 (?:?) kasan_check_range+0x105/0x1b0 (?:?) __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72495", "url": "https://ubuntu.com/security/CVE-2026-72495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid repeated requests to allocate WC pages Applications can request multiple WC pages for the same ucontext. As of now, only 1 WC page per ucontext is supported. Add a lock to avoid concurrent access and a check to fail repeated requests. Also, if the mmap entry insert fails for the WC, free the Doorbell page index mapped for the WC page.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72501", "url": "https://ubuntu.com/security/CVE-2026-72501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Initialize dpi variable to zero dpi is initialized only for BNXT_RE_ALLOC_WC_PAGE, but copied for all the cases. So initialize the dpi to 0.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72278", "url": "https://ubuntu.com/security/CVE-2026-72278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Re-translate VNCR before injecting abort KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor updates and MMU faults.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68083", "url": "https://ubuntu.com/security/CVE-2026-68083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix path resolution in ksmbd_vfs_kern_path_create The SMB2 open lookup is rooted at the share with LOOKUP_BENEATH, but the create/mkdir/hardlink sink is not: ksmbd_vfs_kern_path_create() builds an absolute path with convert_to_unix_name() and resolves it from AT_FDCWD via start_creating_path(), so a \"..\" component is walked from the real filesystem root and escapes the export. An authenticated client races a missing path component so the rooted open lookup returns -ENOENT (taking the create branch) while the same component is present (a directory) when the create walk runs; the create then resolves \"..\" out of the share. Root the create walk at the share like the lookup and rename paths already are: resolve the parent with vfs_path_parent_lookup(..., LOOKUP_BENEATH, &share_conf->vfs_path) and create the final component with start_creating_noperm(). convert_to_unix_name() then has no callers and is removed.", "cve_priority": "high", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-68457", "url": "https://ubuntu.com/security/CVE-2026-68457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use opener credentials for FSCTL mutations SET_SPARSE, SET_ZERO_DATA and SET_COMPRESSION operate on an open SMB handle but call VFS xattr, fallocate or fileattr helpers with the current ksmbd worker credentials. Those helpers can revalidate inode permissions, ownership and LSM policy independently of the SMB handle access mask. Run each operation with the credentials captured in the target file when the handle was opened. Keep credential handling local to these single-file FSCTLs rather than applying session credentials to the complete IOCTL handler, which also contains handle-less and multi-handle operations.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72041", "url": "https://ubuntu.com/security/CVE-2026-72041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: use sk_msg_free_partial to fix partial send sk_msg_free_partial() ensures consistency of the skmsg at every iteration, without having to manually handle uncharges and offsets. This simplifies the code, and fixes some bugs in skmsg accounting when we don't send the full contents.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72046", "url": "https://ubuntu.com/security/CVE-2026-72046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing.", "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-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21: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-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72137", "url": "https://ubuntu.com/security/CVE-2026-72137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: nat_keepalive: avoid double free on send error nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6 send helper reports an error. That cleanup is only correct before the skb is handed to the output path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the networking stack may already have consumed the skb before returning an error, so freeing it again is unsafe. Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4() and nat_keepalive_send_ipv6(), where the caller still owns the skb, and keep nat_keepalive_send() responsible only for family dispatch and the unsupported-family cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72139", "url": "https://ubuntu.com/security/CVE-2026-72139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: defer md5sig_info kfree past RCU grace period in tcp_connect The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: \tif (needs_md5) { \t\ttcp_ao_destroy_sock(sk, false); \t} else if (needs_ao) { \t\ttcp_clear_md5_list(sk); \t\tkfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); \t} Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with tcp-diag]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72191", "url": "https://ubuntu.com/security/CVE-2026-72191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: validate split-point offset in indx_insert_into_buffer indx_insert_into_buffer() computes used = used1 - to_copy - sp_size; memmove(de_t, Add2Ptr(sp, sp_size), used - le32_to_cpu(hdr1->de_off)); where sp and sp_size come from hdr_find_split(). hdr_find_split() walks entries by le16_to_cpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFS_DE). index_hdr_check(), the on-load gatekeeper, only validates header-level fields (used, total, de_off) and does not walk per-entry sizes. A crafted NTFS image whose leaf INDEX_HDR reports used == total but contains one interior NTFS_DE with size = 0xFFF0 therefore passes validation, descends to indx_insert_into_buffer() through the ntfs_create() -> indx_insert_entry() path, and makes hdr_find_split() return an sp whose sp_size (0xFFF0) greatly exceeds the remaining bytes in the buffer. The u32 subtraction underflows and the memmove count becomes a near-4-GiB value, producing an out-of-bounds kernel write that corrupts adjacent allocations and panics the kernel. Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a single 'touch' inside the mounted directory; crash site resolves to fs/ntfs3/index.c at the memmove. Trigger requires only local mount of an attacker-supplied filesystem image (USB, loopback, or removable media auto-mount). Reject the split whenever the chosen sp plus its declared size already extends past hdr1->used. This is the minimal fix; it preserves the existing hdr_find_split() contract and relies on the same out: cleanup path as the pre-existing error returns. A prior OOB read in the very same indx_insert_into_buffer() memmove was fixed in commit b8c44949044e (\"fs/ntfs3: Fix OOB read in indx_insert_into_buffer\") by tightening hdr_find_e(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdr_find_split(), not hdr_find_e(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72217", "url": "https://ubuntu.com/security/CVE-2026-72217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing xdr_buf_to_bvec() writes a bio_vec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it. rq_bvec, the array passed by nfsd_vfs_write(), is allocated to exactly rq_maxpages entries with no slack. The OOB store can land in adjacent slab memory; the bv_len and bv_offset fields written there are derived from client-supplied RPC payload sizes. Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72220", "url": "https://ubuntu.com/security/CVE-2026-72220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp->rq_procinfo->pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72221", "url": "https://ubuntu.com/security/CVE-2026-72221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: wait for in-flight TLS handshake callback when cancel loses race When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed. The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result. If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue. If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed. Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed to fire because handshake_complete() invokes svc_tcp_handshake_done() unconditionally once it has set HANDSHAKE_F_REQ_COMPLETED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72222", "url": "https://ubuntu.com/security/CVE-2026-72222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: pin svc_xprt across the asynchronous TLS handshake callback svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of(). Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done. The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry. Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all(). [cel: rewrote commit message to describe the actual change]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72277", "url": "https://ubuntu.com/security/CVE-2026-72277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the simpler thing for now and just reject everything that isn't memory.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72279", "url": "https://ubuntu.com/security/CVE-2026-72279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR KVM currently maps the L1 VNCR into the host stage-1 by relying entirely on the permissions of the guest stage-1. At the same time, it is entirely possible that the backing PFN is read-only (e.g. RO memslot), meaning that the L1 VNCR should use at most a read-only mapping. Cache the writability of the PFN in the VNCR TLB and use it to constrain the resulting fixmap permissions. Promote VNCR permission faults to an SEA in the case where the guest attempts to write to a read-only endpoint. Conveniently, this also plugs a page leak found by Sashiko [*] resulting from the early return for a read-only PFN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72288", "url": "https://ubuntu.com/security/CVE-2026-72288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling Hyunwoo Kim reports some really bad races should the following situation occur: - LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C If the last two race nicely enough, vgic_prune_ap_list() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows. The fix is two-fold: - Before dropping the irq and ap_list locks, take a reference on the irq - Do not try to handle migration of the pending bit: there is no expectation that this state is retained, as per the architecture With that, we're sure that the interrupt is still around, and we safely remove it from the AP list as it has no target at this stage (unless another interrupt fires, but that's another story).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "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-72317", "url": "https://ubuntu.com/security/CVE-2026-72317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: pin upper rpc_clnt across the TLS connect_worker The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt. The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported. Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one. The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72318", "url": "https://ubuntu.com/security/CVE-2026-72318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate DFS referral string offsets parse_dfs_referrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server. Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative max_len is then passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds. Validate each string offset before deriving the string pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72320", "url": "https://ubuntu.com/security/CVE-2026-72320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_lookup: fix catchall element handling with inverted lookups nft_lookup_eval() decides whether a lookup matched (`found`) from the direct set lookup and priv->invert before falling back to the catchall element used by interval sets (e.g. nft_set_rbtree) for the open-ended default range. Since `found` is never recomputed after `ext` is replaced by the catchall lookup, inverted lookups (NFT_LOOKUP_F_INV, \"!= @set\") can wrongly match or wrongly skip the catchall element, producing the wrong verdict. Fold the catchall lookup into `ext` before computing `found`, matching the order already used by nft_objref_map_eval().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72366", "url": "https://ubuntu.com/security/CVE-2026-72366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_create_write_req() to handle async cache object creation netfs_create_write_req() will skip caching if the fscache cookie is disabled, but this is a problem because async cache object creation might not have got far enough yet that has been enabled - thereby causing the call to fscache_begin_write_operation() to be skipped. Fix this by removing the checks on the cookie and delegating this to fscache_begin_write_operation().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72381", "url": "https://ubuntu.com/security/CVE-2026-72381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of fp->owner.name in durable handle owner check Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d (\"ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd\") made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized. BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8 Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72393", "url": "https://ubuntu.com/security/CVE-2026-72393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: don't cache shinfo across skb realloc fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb including the shared info. We can't use the pointer calculated before the call. BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0 Read of size 4 at addr ff110000262edd98 by task swapper/5/0 Call Trace: fbnic_tx_lso.isra.0+0x668/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 Allocated by task 8653: __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xcc/0x6c0 sock_alloc_send_pskb+0x327/0x3f0 __ip_append_data+0x188b/0x47a0 ip_make_skb+0x24a/0x300 udp_sendmsg+0x14d2/0x21e0 Freed by task 0: kfree+0x123/0x5a0 pskb_expand_head+0x36c/0xfa0 fbnic_tx_lso.isra.0+0x500/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 sch_direct_xmit+0x25b/0x1100 The buggy address belongs to the object at ff110000262edc40 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 344 bytes inside of freed 640-byte region [ff110000262edc40, ff110000262ede", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72398", "url": "https://ubuntu.com/security/CVE-2026-72398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: add INIT verification after cookie unpacking In SCTP handshake, the INIT chunk is initially processed by the server and embedded into the cookie carried in INIT-ACK. The client then returns this cookie via COOKIE-ECHO, where the server unpacks it and reconstructs the original INIT chunk. When cookie authentication is enabled, the cookie contents are protected against tampering, so reusing the unpacked INIT without re-verification is safe. However, when cookie authentication is disabled, the reconstructed INIT can no longer be trusted. In this case, the INIT must be explicitly validated after unpacking to avoid processing potentially tampered data. Add sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO processing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook()) when cookie_auth_enable is disabled. On failure, the new association is freed and the packet is discarded. Also tighten cookie validation in sctp_unpack_cookie() by verifying the embedded chunk type is SCTP_CID_INIT before treating it as an INIT chunk. Finally, update sctp_verify_init() to validate parameter bounds using the actual embedded INIT length instead of chunk->chunk_end, since the INIT stored in COOKIE-ECHO may not span the entire chunk buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72399", "url": "https://ubuntu.com/security/CVE-2026-72399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: check the number of BDs needed for xdp_frame The size of xdp_redirect_arr array is ENETC_MAX_SKB_FRAGS. However, the number of fragments contained in xdp_frame may be greater than or equal to ENETC_MAX_SKB_FRAGS, which will cause the access to xdp_redirect_arr to be out of bounds.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72429", "url": "https://ubuntu.com/security/CVE-2026-72429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix type confusion of dst_entry IOAM uses a dummy dst_entry(null_dst) to mark that the destination should not be changed after the transformation. This dst is stored in the IOAM lwt state and may be passed to dst_cache_set_ip6(). However, the IPv6 dst cache path eventually calls rt6_get_cookie(), which treats the dst_entry as part of a struct rt6_info. Since the null_dst was embedded directly as a struct dst_entry in struct ioam6_lwt, this resulted in an invalid cast and rt6_get_cookie() reading fields from the wrong object. In practice, the wrong cookie is not used while dst->obsolete is zero, but rt6_get_cookie() may also access per-cpu value when rt->sernum is zero. In this case, rt->sernum aliases ioam6_lwt::cache::reset_ts, which can become zero, making this a potential invalid pointer access. Fix this by embedding a full struct rt6_info for the dummy IPv6 route and passing its dst member to the dst APIs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72436", "url": "https://ubuntu.com/security/CVE-2026-72436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash types Sashiko pointed out that there are a few lockless RCU readers using test_bit() which is a relaxed atomic operation and provides no memory barrier guarantees. Use test_bit_acquire() instead where the operation may run parallel with add/del/gc, i.e. is not one from the next cases - protected by region lock - in a set destroy phase - in a new/temporary set creation phase", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72451", "url": "https://ubuntu.com/security/CVE-2026-72451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix xfrm state cache insertion race The xfrm input state cache insertion code checks the validity of the state before acquiring the global xfrm_state_lock. Thus it's possible for someone else to kill the state after it passed the validity check, and then the insertion will add the dead state to the cache. Fix this by moving the validity check inside the lock. This entire function is called on the input path, where BH must be off (e.g., the caller of this function xfrm_input acquires its spinlocks without disabling BH). So there is no need to disable BH here or take the RCU read lock. Remove both and replace them with an assertion that trips if BH is accidentally enabled on some future calling path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72472", "url": "https://ubuntu.com/security/CVE-2026-72472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: use nfsi->rwsem to protect traversal of the file lock list Lingfeng identified a bug and suggested two solutions, but both appear to have issues. Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case. Furthermore, after commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk. Regarding the bug fixed by commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), it has been resolved after commit 0460253913e5 (\"NFSv4: nfs4_do_open() is incorrectly triggering state recovery\") because all slots are drained before calling nfs4_do_reclaim, which prevents concurrent stateid changes along this path. Also, nfs_delegation_claim_locks does not cause this concurrency either since when _nfs4_proc_setlk is called with NFS_DELEGATED_STATE, no RPC is sent, so nfs4_lock_done is not called. Therefore, nfs4_lock_delegation_recall from nfs_delegation_claim_locks is the first time the stateid is set.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72473", "url": "https://ubuntu.com/security/CVE-2026-72473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decouple req recycling from RPC completion rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer. Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off. The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry. Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied. Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected. Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released. The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74310", "url": "https://ubuntu.com/security/CVE-2026-74310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/net: complete zerocopy ubufs only once vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74345", "url": "https://ubuntu.com/security/CVE-2026-74345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix endpoint/socket association handling Disassociating a socket from an endpoint via siw_socket_disassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within. This fixes a: BUG: KASAN: slab-use-after-free in siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1053 drivers/infiniband/sw/siw/siw_cm.c:1075) which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74361", "url": "https://ubuntu.com/security/CVE-2026-74361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: fix FDP fdpcidx bounds check The fdpcidx bounds check sets n = NUMFDPC + 1 but used > instead of >=, incorrectly accepting fdp_idx when it equals n (i.e. NUMFDPC + 1).", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74401", "url": "https://ubuntu.com/security/CVE-2026-74401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix add msg handle in send_queue ordered In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as \"before(mh->seq, seq)\" will stop to check for older sequence numbers that are ordered in the tail of \"node->send_queue\". The side effects of not having it correct ordered regarding \"before(mh->seq, seq)\" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74406", "url": "https://ubuntu.com/security/CVE-2026-74406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74428", "url": "https://ubuntu.com/security/CVE-2026-74428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix double unlock in rxrpc_recvmsg() Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74433", "url": "https://ubuntu.com/security/CVE-2026-74433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix UAF in rxgk_issue_challenge() Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74434", "url": "https://ubuntu.com/security/CVE-2026-74434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Don't move a peeked OOB message onto the pending queue rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so only unlink it from recvmsg_oobq and then move it onto pending_oobq or free it when the message is actually consumed.", "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-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-74439", "url": "https://ubuntu.com/security/CVE-2026-74439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clear Present bit before tearing down scalable-mode context entry device_pasid_table_teardown() zeroes the 128-bit scalable-mode context entry with context_clear_entry() while the Present bit is still set. This creates a window where the hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behavior or spurious faults. The context-cache invalidation is issued only after the entry has been zeroed, and intel_pasid_free_table() then frees the PASID directory pages, so the IOMMU can keep walking a stale Present=1 entry that points at freed memory. While x86 provides strong write ordering, the compiler may reorder the two 64-bit writes to the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Commit c1e4f1dccbe9d (\"iommu/vt-d: Clear Present bit before tearing down context entry\") fixed this exact pattern in domain_context_clear_one() and the copied-context path, but device_pasid_table_teardown() was not converted. Align it with the \"Guidance to Software for Invalidations\" in the VT-d spec, Section 6.5.3.3, using the same ownership handshake as the sibling fix: clear only the Present bit, flush it to the IOMMU, perform the context-cache invalidation, and only then zero the rest of the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" } ], "log": [ "", " * noble/linux-riscv-7.0: 7.0.0-38.38.1~24.04.1 -proposed tracker (LP: #2165483)", "", " [ Ubuntu-riscv: 7.0.0-38.38.1 ]", "", " * resolute/linux-riscv: 7.0.0-38.38.1 -proposed tracker (LP: #2165484)", " * resolute: llvm-21-dev build-depends breaks cross-builds (LP: #2165407)", " - [Packaging] Fix cross-builds", " * Zfhmin/Zvfhmin not reported when Zfh/Zvfh are present (LP: #2166547)", " - riscv: report Zfhmin/Zvfhmin when Zfh/Zvfh are present", " [ Ubuntu: 7.0.0-38.38 ]", " * resolute/linux: 7.0.0-38.38 -proposed tracker (LP: #2166443)", " * linux: dtbs_install fails on Resolute builders due to uutils install(1)", " EEXIST race under parallel make (LP: #2166356)", " - SAUCE: [Packaging] Serialise dtbs_install to work around uutils", " install(1) race", " * #510/p sleepable raw tracepoint reject from test_verifier in ubuntu_bpf", " failed with resolute (7.0.0-33.33) generic amd64 (LP: #2165872)", " - SAUCE: Revert \"bpf: Verifier support for sleepable tracepoint programs\"", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189)", " - 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", " - seqlock: Allow UBSAN_ALIGNMENT to fail optimizing", " - KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN", " - crypto: tegra - Don't touch bo refcount in host1x bo pin/unpin", " - xprtrdma: Clear receive-side ownership pointers on release", " - Input: ims-pcu - fix logic error in packet reset", " - fuse: fix writeback array overflow when max_pages is one", " - arm64: tegra: Remove fallback compatible for GPCDMA", " - arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234", " - xfrm: propagate -EINPROGRESS from validate_xmit_xfrm()", " - mtd: mtdswap: remove debugfs stats file on teardown", " - mtd: nand: mtk-ecc: stop on ECC idle timeouts", " - btrfs: fallback to transaction csum tree on a commit root csum miss", " - RDMA/cma: Fix hardware address comparison length in netevent callback", " - RDMA/irdma: Remove redundant legacy_mode checks", " - RDMA/erdma: initialize ret for empty receive WR lists", " - RDMA/mana_ib: initialize err for empty send 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: cfg80211: derive S1G beacon TSF from S1G fields", " - wifi: nl80211: validate nested MBSSID IE blobs", " - wifi: nl80211: constrain MBSSID TX link ID range", " - wifi: cfg80211: validate PMSR measurement type data", " - wifi: cfg80211: reject unsupported PMSR FTM location requests", " - wifi: mac80211: avoid non-S1G AID fallback for S1G assoc", " - ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on", " start/stop", " - ASoC: amd: ps: disable MSI on resume in ACP PCI driver", " - ASoC: amd: ps: fix wrong ACP version string in pci_request_regions()", " - ASoC: amd: ps: replace bitwise OR with logical OR in IRQ return check", " - 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", " - cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq", " - udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()", " - ata: sata_dwc_460ex: use platform_get_irq()", " - ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending", " interrupts", " - accel/ivpu: Fix wrong register read in LNL failure diagnostics", " - ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC", " - drm/i915/gt: use correct selftest config symbol", " - powerpc/85xx: Add fsl,ifc to common device ids", " - powerpc/time: Prepare to stop elapsing in dynticks-idle", " - powerpc/vtime: Initialize starttime at boot for native accounting", " - drm/panthor: Check debugfs GEM lock initialization", " - riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()", " - can: j1939: fix lockless local-destination check", " - drm/xe/wopcm: fix WOPCM size for LNL+", " - drm/i915/wm: clear the plane ddb_y entries on plane disable", " - 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: gadget: fsl-udc: fix dev_printk() device", " - 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", " - SAUCE: Revert \"usb: typec: ucsi: Detect and skip duplicate altmodes from", " buggy firmware\"", " - usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware", " - wifi: mwifiex: fix freeze for 60 seconds caused by request_firmware", " - RISC-V: KVM: Serialize virtual interrupt pending state updates", " - Revert \"drm/amd/display: Add missing kdoc for ALLM parameters\"", " - usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits", " - selftests/bpf: Adjust verifier_map_ptr for the map's excl field", " - selftests/bpf: Keep verifier_map_ptr exercising ops pointer access", " - 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", " - btrfs: fix u32 to s64 type conversion in dirty_metadata_bytes accounting", " - ASoC: sun4i-codec: Set quirks.playback_only for H616 codec", " - 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: fix pointer arithmetic in iwl_add_mcc_to_tas_block_list", " - wifi: iwlwifi: validate payload length in iwl_pnvm_complete_fn", " - wifi: iwlwifi: mvm: fix read in wake packet notification handler", " - usb: atm: ueagle-atm: reject descriptors that confuse probe and", " disconnect", " - drivers/virt: pkvm: Fix end calculation in mmio_guard_ioremap_hook()", " - 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", " - selftests/net: ovpn: fix getaddrinfo memory leak in ovpn_parse_remote()", " - ovpn: use monotonic clock for peer keepalive timeouts", " - regulator: mt6358: use regmap helper to read fixed LDO calibration", " - net: phy: marvell: fix return code", " - netlink: specs: rt-link: convert bridge port flag attributes to u8", " - gtp: parse extension headers before reading inner protocol", " - vhost-net: fix TX stall when vhost owns virtio-net header", " - wifi: mac80211: recalculate TIM when a station enters power save", " - pds_core: reject component parameter in legacy firmware update", " - arm64: Correct value returned by ESR_ELx_FSC_ADDRSZ_nL()", " - amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN", " - soreuseport: Clear sk_reuseport_cb before failure in sk_clone().", " - net: Call net_enable_timestamp() before failure in sk_clone().", " - 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", " - selftests: af_unix: add USER_NS config", " - selftests: openvswitch: add config file", " - selftests: ovpn: add IPV6 and VETH configs", " - selftests: ovpn: increase timeout", " - selftests: drv-net: increase timeout", " - ppp: don't store tx skb in the fastpath", " - ppp: annotate concurrent dev->stats accesses", " - ovl: fix trusted xattr escape prefix matching", " - drm/panel: s6e3ha8: fix unmet dependency on DRM_DISPLAY_HELPER", " - 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", " - drm/xe/i2c: Allow per domain unique id", " - iomap: correct the range of a partial dirty clear", " - drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem", " - net: stmmac: xgmac: fix l4 filter port overwrite on register update", " - 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: annotate data races in ppp_generic", " - hinic: remove unused ethtool RSS user configuration buffers", " - raw: annotate lockless match fields in raw_v4_match()", " - 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", " - octeontx2-pf: tc: fix egress ratelimiting", " - net: ipv6: fix dif and sdif mismatch in raw6_icmp_error", " - ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV", " - ice: fix LAG recipe to profile association", " - ipv6: Change allocation flags to match rcu_read_lock section", " requirements", " - ptp: netc: explicitly clear TMR_OFF during initialization", " - mctp: check register_netdevice_notifier() error in mctp_device_init()", " - net: airoha: fix ETS channel derivation in airoha_tc_setup_qdisc_ets()", " - drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay", " - drm: renesas: rzg2l_mipi_dsi: Move rzg2l_mipi_dsi_set_display_timing()", " - drm/tidss: Fix missing drm_bridge_add() call", " - 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/sysfb: Do not page-align visible size of the framebuffer", " - drm/sysfb: Avoid truncating maximum stride", " - drm/amdgpu/gfx9: Fix Ring and IB test fail after mode2", " - drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT", " - drm/sysfb: Return errno code from drm_sysfb_get_visible_size()", " - drm/displayid: fix Tiled Display Topology ID size", " - drm/nouveau/acr: fix missing nvkm_done() in error path of", " nvkm_acr_oneinit()", " - drm/radeon: fix r100_copy_blit for large BOs", " - drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked binds", " - drm/amdkfd: Use kvcalloc to allocate arrays", " - drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips", " - drm/i915/hdcp: require monotonically increasing seq_num_v", " - drm/amd/amdgpu: disable ASPM on VI if pcie dpm is disabled", " - drm/amd/pm: fix smu14 power limit range calculation", " - drm/gfx10: Program DB_RING_CONTROL", " - drm/virtio: Don't detach GEM from a non-created context", " - drm/panthor: return error on truncated firmware", " - drm/amdgpu: Fix VFCT bus number matching with soft filter", " - drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)", " - drm/amd/display: consolidate DCN vblank/flip handling onto", " vupdate_no_lock", " - drm/amd/display: Force PWM backlight on Lenovo Legion 5 15ARH05", " - drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge", " - drm/amd/display: Fix flip-done timeouts on mode1 reset", " - drm/amd/display: Fix missing DCE check in", " dm_gpureset_toggle_interrupts()", " - drm/v3d: Reach the GMP through the hub registers on V3D 7.x", " - 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: imx219: Fix maximum frame length in lines", " - media: iris: Fix use IRQF_NO_AUTOEN when requesting the IRQ", " - media: marvell-cam: fix missing pci_disable_device() on remove", " - media: nuvoton: npcm-video: fix error handling in npcm_video_init()", " - 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: qcom: camss: Fix RDI streaming for CSID 680", " - media: qcom: camss: Fix RDI streaming for CSID GEN2", " - media: qcom: camss: Fix RDI streaming for CSID GEN3", " - media: rzg2l-cru: Skip ICnMC configuration when ICnSVC is used", " - media: synopsys: hdmirx: Fix HPD lane hold time", " - 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: v4l2-subdev: Fail {enable,disable}_streams and s_streaming nicely", " - media: vb2: use ssize_t for vb2_read/vb2_write", " - media: verisilicon: Export only needed pixels formats", " - media: vidtv: fix reference leak on failed device registration", " - media: vimc: fix reference leak on failed device registration", " - media: vpif_capture: fix OF node reference imbalance", " - ALSA: hda/realtek: Fix speakers on Lunnen Ground 14", " - ALSA: hda: codecs: hdmi: disable keep-alive before audio format change", " - wifi: brcmfmac: set F2 blocksize to 256 for BCM43752", " - wifi: ath11k: fix refcount leak in ath11k_ahb_fw_resources_init()", " - staging: rtl8723bs: fix inverted HT40 secondary channel offset", " - platform/loongarch: laptop: Explicitly reset bl_powered state when", " suspend", " - rust_binder: only print failure if error has source", " - rust: time: fix as_micros_ceil() to round correctly for negative Delta", " - rust: allow `clippy::unwrap_or_default` globally", " - objtool/rust: add one more `noreturn` Rust function for Rust 1.99.0", " - LoongArch: Fix address space mismatch in kexec command line lookup", " - LoongArch: Fix oops during single-step debugging", " - LoongArch: Move jump_label_init() before parse_early_param()", " - LoongArch: Retrieve CPU package ID from PPTT when available", " - x86/boot/compressed: Disable jump tables", " - uio_hv_generic: Bind to FCopy device by default", " - serial: sc16is7xx: implement gpio get_direction() callback", " - selftests: ntsync: correct CONFIG_NTSYNC name", " - tracing: Fix context switch counter truncation", " - 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()", " - mptcp: decrement subflows counter on failed passive join", " - mptcp: only set DATA_FIN when a mapping is present", " - mm/kmemleak: fix checksum computation for per-cpu objects", " - mm/huge_memory: set PG_has_hwpoisoned only after new folio head is", " established", " - ceph: fix refcount leak in ceph_readdir()", " - ceph: fix writeback_count leak in write_folio_nounlock()", " - ASoC: fsl: imx-card: Skip sysclk reset for active DAIs in shutdown", " - ASoC: fsl_sai: Fix spurious BCLK on resume by clearing BYP", " - io_uring/rw: fix missing ERESTARTSYS conversion in read paths", " - iommu/vt-d: Disallow SVA if page walk is not coherent", " - net: stmmac: intel: skip SerDes reconfig when rate is unchanged", " - net: pcs: xpcs: fix SGMII state reading", " - proc: Fix broken error paths for namespace links", " - s390/ptff: Export ptff_function_mask[]", " - smb: client: handle STATUS_STOPPED_ON_SYMLINK responses without a", " symlink target", " - ice: use READ_ONCE() to access cached PHC time", " - ovpn: hold peer before scheduling keepalive work", " - vsock/virtio: collapse receive queue under memory pressure", " - watchdog: s32g_wdt: remove incorrect options in watchdog_info struct", " - drm/amd/pm: fix amdgpu_pm_info power display units", " - drm/amd/pm: make pp_features read-only when scpm is enabled", " - drm/amdgpu/jpeg: fix jpeg_v4_0_3_is_idle detection", " - drm/amdgpu/jpeg: fix jpeg_v5_0_1_is_idle detection", " - drm/amdgpu/soc24: reset dGPU if suspend got aborted", " - drm/amdgpu: fix resource leak on ACP reset timeout", " - drm/amd/pm: fix smu13 power limit range calculation", " - drm/amdgpu: fix check in amdgpu_hmm_invalidate_gfx", " - drm/xe/uapi: Reject coh_none PAT index for CPU_ADDR_MIRROR", " - net: qrtr: ns: Raise node count limit to 512", " - drm/amd/display: Fix DTB DTO updates breaking live pixel rate sources", " - audit: widen ino fields to u64", " - audit: use 'unsigned int' instead of 'unsigned'", " - xfs: don't replace the wrong part of the cow fork", " - netfilter: nf_tables: remove register tracking infrastructure", " - drm: drop lib from header search path.", " - SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlists", " - SUNRPC: Return an error from xdr_buf_to_bvec() on overflow", " - SAUCE: Revert \"mm/sparse-vmemmap: fix vmemmap accounting underflow\"", " - mm/sparse-vmemmap: fix vmemmap accounting underflow", " - mmc: vub300: rename probe error labels", " - net: mana: Optimize irq affinity for low vcpu configs", " - bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c", " - bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()", " - pmdomain: imx93-blk-ctrl: convert to devm_* only", " - rust: allow `suspicious_runtime_symbol_definitions` lint for Rust >=", " 1.98", " - rust: device: avoid trailing ; in printing macros", " - sched_ext: Skip ops.set_weight() for disabled tasks", " - sched_ext: Annotate ksyncs with __rcu in alloc/free_kick_syncs()", " - reset: spacemit: k3: fix USB2 ahb reset", " - wifi: cfg80211: reject empty PMSR peer lists", " - ASoC: amd: acp: Fix linker error with SDCA quirks", " - [Config] Adjust config SND_SOC_ACPI_AMD_SDCA_QUIRKS", " - sched_ext: Enable tick for finite slices on nohz_full", " - Bluetooth: mgmt: Translate HCI reason in Device Disconnected event", " - riscv: Gate FUNCTION_ALIGNMENT_4B on DYNAMIC_FTRACE", " - spi: cadence-quadspi: Fix indirect write timeout when DMA read mode is", " enabled", " - drm/xe: Assign queue name in time for drm_sched_init", " - drm/xe: add WQ_PERCPU to alloc_workqueue users", " - selftests: netconsole: only restore MAC when it changed on resume", " - wifi: ath10k: fix skb leak on incomplete msdu during rx pop", " - wifi: ath12k: Fix low MLO RX throughput on WCN7850", " - iommu/amd: Fix nested domain leak", " - arm_mpam: Fix software reset values of MPAMCFG_PRI", " - arm_mpam: Fix MPAMCFG_MBW_PBM register setting", " - hwmon: Drop unused i2c driver_data", " - hwmon: Use named initializers for arrays of i2c_device_data", " - hwmon: (pmbus/max34440): add support adpm12250", " - hwmon: (pmbus/max34440) block unsupported VIN and IIN limit registers", " - drm/i915/backlight: Remove DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check for", " DPCD backlight", " - selftests/net: Fix tun IPv6 test addresses to avoid 6to4 range", " - geneve: fix hint header definition wrt endianness", " - geneve: ensure the skb is writable before fixing its headers", " - accel: ethosu: Handle U85 internal chaining buffer", " - selftests: drv-net: convert so_txtime to drv-net", " - cifs: prevent readdir from changing file size due to stale directory", " metadata", " - wifi: mt76: fix airoha_npu dependency tracking", " - [Config] Fix config dependencies for MT76_NPU", " - drm/panel: ilitek-ili9882t: fix unmet dependency for", " DRM_PANEL_ILITEK_ILI9882T", " - iomap: fix incorrect did_zero setting in iomap_zero_iter()", " - mpls: Set rt->rt_nhn just before returning from mpls_nh_build_multi().", " - LoongArch: BPF: Zero-extend signed ALU32 div/mod results", " - bnge/bng_re: fix ring ID widths", " - pidfs: make pidfs_ino_lock static", " - LoongArch: BPF: Fix memory leak in bpf_jit_free()", " - drm/exynos: fbdev: Remove offset into screen_buffer", " - drm/tegra: fbdev: Remove offset into framebuffer memory", " - drm/i915/cdclk: Fix up CDCLK_FREQ_DECIMAL without a full PLL re-enable", " - drm/amd/pm: re-enable MC access after PrepareMp1ForUnload on SMU V15", " APUs", " - bitmap: add test_zero_nbits()", " - drm/xe: Add compact-PT and addr mask handling for page reclaim", " - drm/amd/display: Restore periodic detection for DCN35", " - drm/amdgpu: Respect placement requirements in amdgpu_gtt_mgr functions", " - drm/amdkfd: Use exclusive bounds for SVM split alignment checks", " - drm/i915/mtl+: Enable PPS before PLL", " - drm/xe/oa: Fix offset alignment for MERT WHITELIST_OA_MERT_MMIO_TRG", " - drm/xe/nvm: fix writable override for CRI", " - drm/amdgpu: Check for multiplication overflow in checkpoint stack size", " - drm/amdkfd: Guard m->cp_hqd_eop_control setting by", " q->eop_ring_buffer_size", " - drm/amdkfd: free MQD managers on DQM init failures", " - drm/amd/display: set MSA MISC1 bit 6 when using VSC SDP for DCE 11.x", " - drm/amdgpu: add the doorbell index input for suspending userq", " - drm/amdgpu: remove deadlocks from amdgpu_userq_pre_reset", " - drm/amd: Create a device link between APU display and XHCI devices", " - drm/pagemap: Clear driver-provided PFNs from migration PFN array", " - mm: add gpu active/reclaim per-node stat counters (v2)", " - drm/ttm: use gpu mm stats to track gpu memory allocations. (v4)", " - drm/ttm: Fix GPU MM stats during pool shrinking", " - drm/ttm/pool: back up at native page order", " - drm/gpusvm: Zero HMM PFNs before scanning ranges", " - media: mali-c55: Add missing of_reserved_mem_device_release()", " - media: mali-c55: Disable pm_runtime on probe error", " - media: mali-c55: Power-off the peripheral in remove()", " - media: qcom: camss: Fix RDI streaming for CSID 340", " - media: rzv2h-ivc: Wait for frame end in stop_streaming", " - media: ti: vpe: Fix fwnode_handle leak in vip_probe_complete()", " - media: ti: vpe: Fix the error code of devm_request_irq()", " - media: uapi: rkisp: Correct name version enum", " - wifi: mt76: restrict NPU/PPE active checks to MMIO devices", " - LoongArch: Fix build errors due to wrong instructions for 32BIT", " - LoongArch: Increase TASK_STRUCT_OFFSET up to 2040 for 32BIT", " - firmware: stratix10-svc: fix teardown order in remove to prevent race", " - firmware: stratix10-svc: handle NO_RESPONSE in async poll", " - tracing: perf: Fix stale head for perf syscall tracing", " - 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\"", " - selftests: mptcp: userspace_pm: fix undefined variable port", " - m68k: avoid -Wunused-but-set-parameter in clear_user_page()", " - mm/memory-failure: trace: change memory_failure_event to ras subsystem", " - mm/slub: fix lost local objects when bulk remote free batch fills", " - mm/slab: fix a memory leak due to bootstrapping sheaves twice", " - drm/amdgpu: rework userq fence driver alloc/destroy", " - drm/amdgpu: rework userq fence signal processing", " - drm/amdgpu/gfx11: fix EOP interrupt routing for KQ and userq", " - drm/amdgpu/gfx12: fix EOP interrupt routing for KQ and userq", " - drm/amdgpu/mes11: set doorbell offset for suspending userq", " - selftests: drv-net: add missing kconfig for psp.py", " - mm/sparse-vmemmap: pass @pgmap argument to memory deactivation paths", " - mm/sparse-vmemmap: fix DAX vmemmap accounting with optimization", " - selftests: drv-net: cope with slow env in so_txtime.py test", " - selftests: drv-net: so_txtime: relax variance bounds", " - cifs: fix time_last_write stamp placement in setattr/truncate paths", " - cifs: consolidate time_last_write stamp into _cifsFileInfo_put()", " - Upstream stable to v6.18.41, v6.18.42, v6.18.43, v7.1.6, v7.1.7", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68480", " - x86/bugs: Make Safe-RET robust against interrupt injection", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68105", " - drm/amdgpu: Fix kernel panic during driver load failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68109", " - drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68114", " - drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68431", " - ksmbd: validate minimum PDU size for transform requests", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68138", " - net/sched: serialize qdisc_rtab_list against concurrent get/put", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68082", " - libceph: fix two unsafe bare decodes in decode_lockers()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68159", " - libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68163", " - mm/page_vma_mapped: fix device-private PMD handling", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68166", " - userfaultfd: prevent registration of special VMAs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68170", " - mptcp: fix stale skb->sk reference on subflow close", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68177", " - tracing: Delay module ref count for \"enable_event\" trigger", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68191", " - wifi: ath12k: fix NULL pointer dereference in rhash table destroy", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64586", " - wifi: brcmfmac: drain bus_reset work on device removal", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68208", " - media: ti: vpe: Fix the error code of devm_kzalloc() in", " vip_probe_slice()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68224", " - media: mali-c55: Fix possible ERR_PTR in enable_streams", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68237", " - drm/amdgpu/userq: fix indefinite fence wait during GPU reset", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68240", " - drm/gpusvm: publish dpagemap early to avoid device mapping leak on error", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68242", " - drm/i915/gt: Fix NULL deref on sched_engine alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68254", " - drm/i915/vrr: require valid min/max vfreq for VRR", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68436", " - drm/amd/display: use kvzalloc to allocate struct dc", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68447", " - drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68264", " - drm/xe/pt: Reset current_op in xe_pt_update_ops_init()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68265", " - drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68267", " - drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68273", " - drm/amdgpu: Fix context pstate override handling", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68274", " - drm/xe/guc: Fix buffer overflow in steered register list allocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68283", " - tracing: Fix use-after-free freeing trigger private data", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68286", " - drop_monitor: perform u64_stats updates under IRQ-disabled section", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68287", " - drop_monitor: fix size calculations for 64-bit attributes", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68288", " - net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68289", " - tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68291", " - idpf: fix max_vport related crash on allocation error during init", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68303", " - drm/vc4: hvs/v3d: Fix null dereference in unbind", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68312", " - cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain", " paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68316", " - accel: ethosu: Fix element size accounting for cmd stream validation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68322", " - rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68440", " - net: txgbe: fix heap overflow when reading module EEPROM", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68323", " - tipc: serialize udp bearer replicast list updates", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68441", " - net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68337", " - bpf: Reject redirect helpers without a bpf_net_context", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68345", " - arm_mpam: guard MBWU state before adding it to garbage", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68347", " - iommu/amd: Fix IRQ unsafe locking in gdom allocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68375", " - bnxt_en: Handle partially initialized auxiliary devices", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68382", " - drm/xe/guc: Hold device ref until queue teardown completes", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68383", " - drm/xe/guc: Keep scheduler timeline name alive", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68390", " - Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68399", " - bpf: Fix UAF in sock clone early bailouts", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68404", " - wifi: cfg80211: use wiphy work for socket owner autodisconnect", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64581", " - xfrm: fix sk_dst_cache double-free in xfrm_user_policy()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68093", " - KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision", " after hotplug", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68367", " - usb: gadget: f_tcm: synchronize delayed set_alt with teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68164", " - mm/damon/core: disallow overlapping input ranges for damon_set_regions()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68165", " - mm/damon/core: validate ranges in damon_set_regions()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68095", " - fuse-uring: fix race between registration and connection abortion", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68096", " - audit: fix recursive locking deadlock in audit_dupe_exe()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68147", " - fscrypt: Avoid dynamic allocation in fscrypt_get_devices()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68097", " - ksmbd: validate ACE size against SID sub-authorities", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68098", " - ksmbd: bound DACL dedup walk to copied ACEs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68099", " - ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68100", " - ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68173", " - ublk: wait on ublk_dev_ready() instead of ub->completion", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68104", " - drm/amdgpu: invoke pm_genpd_remove() before freeing genpd", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68106", " - drm/amdgpu: fix division by zero with invalid uvd dimensions", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68429", " - drm/dp_mst: Handle torn-down topology gracefully in", " drm_dp_mst_topology_queue_probe()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68107", " - drm/amdgpu/vcn4: avoid rereading IB param length", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68108", " - drm/amdgpu/vce: fix integer overflow in image size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68110", " - drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68111", " - drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68112", " - drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68430", " - drm/amdgpu/gfx8: drop unecessary BUG_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68113", " - drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68246", " - drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68115", " - drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68116", " - vxlan: mdb: Fix source list corruption on a failed replace", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68117", " - tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68118", " - tcp: challenge ACK for non-exact RST in SYN-RECEIVED", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68119", " - tcp: initialize standalone TCP-AO response padding", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68120", " - rtase: Workaround for TX hang caused by hardware packet parsing", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68121", " - pppoe: reload header pointer after dev_hard_header()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68122", " - ovpn: fix peer refcount leak in TCP error paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68123", " - openvswitch: fix GSO userspace truncation underflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68124", " - mctp: serial: handle zero-length frames to prevent rx buffer overflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68125", " - mac802154: llsec: reject frames shorter than the authentication tag", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68126", " - mac802154: hold an interface reference across the scan worker", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68127", " - ila: reload IPv6 header after pskb_may_pull in checksum adjust", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68128", " - ice: reject out-of-range ptype in ice_parser_profile_init", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68129", " - gve: fix Rx queue stall on alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68130", " - ksmbd: defer destroy_previous_session() until after NTLM authentication", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68131", " - rbd: Reset positive result codes to zero in object map update path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68132", " - super: fix emergency thaw deadlock on frozen block devices", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68133", " - ice: fix PTP Call Trace during PTP release", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68134", " - ptp: ptp_s390: Add missing facility check", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68135", " - net: hip04: fix RX buffer leak on build_skb failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68136", " - net: gro: fix double aggregation of flush-marked skbs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68137", " - net/x25: fix use-after-free in x25_kill_by_neigh()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68139", " - net/mlx5e: Use sender devcom for MPV master-up", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68140", " - net/iucv: fix use-after-free of a severed iucv_path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68141", " - net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68142", " - geneve: require CAP_NET_ADMIN in the device netns for changelink", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68143", " - net: slip: serialize receive against buffer reallocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68432", " - vxlan: require CAP_NET_ADMIN in the device netns for changelink", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68144", " - phonet: pep: fix use-after-free in pep_get_sb()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68145", " - iomap: fix out-of-bounds bitmap_set() with zero-length range", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68146", " - ftrace: Add global mutex to serialize trace_parser access", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68148", " - fscrypt: Add missing superblock check in find_or_insert_direct_key()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68149", " - fs: preserve ACL_DONT_CACHE state in forget_cached_acl()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68150", " - fs/super: fix emergency thaw double-unlock of s_umount", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68151", " - binfmt_elf_fdpic: only honour the first PT_INTERP", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68152", " - amt: fix use-after-free in AMT delayed works", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68153", " - libceph: remove debugfs files before client teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68154", " - libceph: reject zero bucket types in crush_decode", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68155", " - libceph: Reject monmaps advertising zero monitors", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68156", " - libceph: refresh auth->authorizer_buf{,_len} after authorizer update", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68157", " - libceph: guard missing CRUSH type name lookup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68158", " - libceph: Fix multiplication overflow in decode_new_up_state_weight()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68433", " - libceph: bound get_version reply decode to front len", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68160", " - ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68161", " - sctp: close UDP tunnel sockets during netns teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68162", " - sctp: avoid auth_enable sysctl UAF during netns teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64564", " - sctp: don't free the ASCONF's own transport in DEL-IP processing", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68168", " - afs: Fix afs_edit_dir_remove() to get, not find, block 0", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68169", " - mptcp: pm: userspace: fix use-after-free in get_local_id", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68172", " - arm64: make huge_ptep_get handled unaligned addresses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68174", " - tracing: Fix union collision of module and refcnt for dynamic events", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68175", " - tracing: Fix resource leak on mmiotrace trace_pipe close", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68176", " - tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68178", " - misc: nsm: pin the module while the device is open", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68179", " - misc: nsm: only unlock nsm_dev on post-lock error paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68180", " - intel_th: fix MSC output device reference leak", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68181", " - mei: bus: access mei_device under device_lock on cleanup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68434", " - serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR", " platforms", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68182", " - comedi: comedi_parport: deal with premature interrupt", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68183", " - firmware: stratix10-svc: fix memory leaks and list corruption bugs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64563", " - rhashtable: clear stale iter->p on table restart", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68184", " - cdrom: fix stack out-of-bounds read in CDROMVOLCTRL", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68186", " - binfmt_misc: set have_execfd only once the interpreter is opened", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68187", " - exec: fix unsigned loop counter wrap in transfer_args_to_stack()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68188", " - Bluetooth: RFCOMM: Fix session UAF in set_termios", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68189", " - Bluetooth: hci_sync: Protect UUID list traversal", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68190", " - staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68192", " - wifi: brcmfmac: make release_scratchbuffers idempotent", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68193", " - wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68194", " - wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68195", " - wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68196", " - wifi: wilc1000: validate assoc response length before subtracting header", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68197", " - wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-", " oper", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68198", " - wifi: ath6kl: fix use-after-free in aggr_reset_state()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68199", " - wifi: ath6kl: fix OOB access from firmware ADDBA window size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68200", " - ALSA: timer: don't re-enter an instance callback that is still running", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68201", " - ALSA: timer: drain a slave's callback before its master detaches it", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68202", " - ALSA: seq: close a re-opened queue timer in the destructor", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68203", " - media: vivid: fix cleanup bugs in vivid_init()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68204", " - media: vivid: check for vb2_is_busy() when toggling caps", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68205", " - media: v4l2-fwnode: Fix subdev owner overwritten in", " v4l2_async_register_subdev_sensor()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68206", " - media: v4l2-ctrls: validate HEVC active reference counts", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68207", " - media: ti: vpe: unwind v4l2 device registration on probe error", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68209", " - media: sun4i-csi: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68210", " - media: stm32: dcmi: unregister notifier on probe failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68211", " - media: stm32-dcmipp: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68212", " - media: saa7134: Fix a possible memory leak in saa7134_video_init1", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68213", " - media: rtl2832_sdr: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68214", " - media: rtl2832: fix use-after-free in rtl2832_remove()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68215", " - media: radio-si476x: Unregister v4l2_device on probe failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68216", " - media: pwc: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68217", " - media: pwc: Drain fill_buf on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68218", " - media: pci: dm1105: Free allocated workqueue", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68219", " - media: nxp: imx8-isi: Fix potential out-of-bounds issues", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68220", " - media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and", " pipe", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68221", " - media: nuvoton: npcm-video: fix memory leaks in probe and remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68222", " - media: msi2500: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68223", " - media: meson: vdec: Fix memory leak in error path of vdec_open", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68225", " - media: i2c: alvium: fix critical pointer access in alvium_ctrl_init", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68226", " - media: cx23885: add ioremap return check and cleanup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68227", " - media: cx231xx: fix devres lifetime", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68228", " - media: chips-media: wave5: Move src_buf Removal to finish_encode", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68229", " - media: cedrus: skip invalid H.264 reference list entries", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68230", " - media: amlogic-c3: Add validations for ae and awb config", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68231", " - media: airspy: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68232", " - drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68445", " - drm/vc4: Prevent shader BO mappings from becoming writable", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68446", " - drm/vmwgfx: Validate vmw_surface_metadata::array_size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68233", " - drm/vc4: Shut down BO cache timer before teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68234", " - drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68235", " - drm/amd/display: dce100: skip non-DP stream encoders for DP MST", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68236", " - drm/amd/display: set new_stream to NULL after release", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68238", " - drm/amdgpu: Release VFCT ACPI table reference", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68239", " - drm/ttm: Account for NULL and handle pages in ttm_pool_backup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68241", " - drm/i915/mst: limit DP MST ESI service loop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68243", " - drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68244", " - drm/i915/gem: Do not leak siblings[] on proto context error", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68245", " - drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68247", " - drm/i915/bios: range check LFP Data Block panel_type2", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68248", " - drm/i915: Return NULL on error in active_instance", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68249", " - drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68250", " - drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68251", " - drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68252", " - drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68253", " - drm/i915/hdcp: check streams[] bounds before overflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68255", " - drm/virtio: bound EDID block reads to the response buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68256", " - drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path", " leaks prev_sink reference", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68257", " - drm/amdkfd: fix 32-bit overflow in CWSR total size calculation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68258", " - drm/amdkfd: Check bounds on CRIU restore queue type and mqd size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68259", " - drm/amdkfd: Check bounds in allocate_event_notification_slot", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68260", " - drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68261", " - drm/imagination: fix error checking of pvr_vm_context_lookup()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68262", " - drm/imagination: Fix user array stride in pvr_set_uobj_array()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68263", " - drm/imagination: Fix double call to drm_sched_entity_fini()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68266", " - drm/xe: Hold a dma-buf reference for imported BOs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68268", " - drm/xe: Return error on non-migratable faults requiring devmem", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68269", " - drm/i915/gem: Add missing nospec on parallel submit slot", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68270", " - drm/sysfb: Avoid possible truncation with calculating visible size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68271", " - drm/nouveau: fix reversed error cleanup order in ucopy functions", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68272", " - drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68275", " - drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68276", " - drm/amdgpu/gfx: fix cleaner shader IB buffer overflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68277", " - drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68437", " - drm/imagination: Fit paired fragment job in the correct CCCB", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68278", " - drm/dp/mst: fix buffer overflows in sideband chunk accumulation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68279", " - drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68280", " - drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68281", " - drm/imagination: Count paired job fence as dependency in prepare_job()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68282", " - drm/rockchip: analogix_dp: Add missing error check for", " platform_get_resource()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68284", " - bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68290", " - rds: tcp: unregister sysctl before tearing down listen socket", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68292", " - ice: prevent tstamp ring allocation for non-PF VSI types", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68293", " - net/mlx5: Fix MCIA register buffer overflow on 32 dword reads", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68294", " - net: qrtr: restrict socket creation to the initial network namespace", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68296", " - net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64575", " - bpf: tcp: fix double sock release on batch realloc", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68297", " - tipc: fix u16 MTU truncation in media and bearer MTU validation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68298", " - drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68299", " - vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68300", " - sctp: auth: verify auth requirement when auth_chunk is NULL", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68301", " - net: hsr: fix memory leak on slave unregistration by removing synced", " VLANs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68302", " - amt: re-read skb header pointers after every pull", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68448", " - ovl: check access to copy_file_range source with src mounter creds", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68304", " - wifi: brcmfmac: fix 802.1X-SHA256 call trace warning", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68306", " - wifi: mt76: mt7996: fix possible NULL-pointer deref in", " mt7996_mcu_sta_bfer_eht()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68307", " - wifi: mt76: mt7925: fix crash in reset link replay", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68308", " - wifi: mt76: mt7996: check pointer returned by", " mt76_connac_get_he_phy_cap()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68439", " - wifi: mt76: mt7925: fix possible NULL-pointer deref in", " mt7925_mcu_bss_he_tlv()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68309", " - wifi: mt76: connac: fix possible NULL-pointer deref in", " mt76_connac_mcu_uni_bss_he_tlv()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68310", " - wifi: mt76: mt7915: guard HE capability lookups", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68311", " - wifi: mt76: mt7925: guard link STA in decap offload", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68313", " - tipc: fix infinite loop in __tipc_nl_compat_dumpit", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64576", " - nexthop: initialize extack in nh_res_bucket_migrate()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64577", " - gtp: check skb_pull_data() return in gtp1u_send_echo_resp()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68314", " - net: mctp i3c: clean up notifier and buses if driver register fails", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68315", " - sctp: validate stream count in sctp_process_strreset_inreq()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68317", " - pds_core: fix auxiliary device add/del races", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68318", " - pds_core: fix use-after-free on workqueue during remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68319", " - pds_core: fix deadlock between reset thread and remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68320", " - sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68321", " - net: txgbe: fix FDIR filter leak on remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68324", " - iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68325", " - iommu/amd: Bound the early ACPI HID map", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68326", " - wifi: mwifiex: bound uAP association event IEs to the event buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68327", " - wan: wanxl: Only reset hardware after BAR mapping", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68328", " - nfp: Check resource mutex allocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64574", " - wifi: mac80211: tear down new links on vif update error path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68329", " - iommu/amd: Wait for completion instead of returning early in", " iommu_completion_wait()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68330", " - net: airoha: Fix DMA direction for NPU mailbox buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68331", " - dpaa2-eth: put MAC endpoint device on disconnect", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68332", " - net: airoha: Fix potential use-after-free in airoha_ppe_deinit()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68333", " - dpaa2-switch: put MAC endpoint device on disconnect", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68334", " - rxrpc: fix io_thread race in rxrpc_wake_up_io_thread()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68335", " - rds: drop incoming messages that cross network namespace boundaries", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68336", " - bonding: fix devconf_all NULL dereference when IPv6 is disabled", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68338", " - net/packet: avoid fanout hook re-registration after unregister", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68339", " - Bluetooth: btusb: validate Realtek vendor event length", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68340", " - hwmon: occ: validate poll response sensor blocks", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68341", " - ovpn: fix use after free in unlock_ovpn()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68342", " - ovpn: avoid putting unrelated P2P peer on socket release", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68343", " - smb: client: validate DFS referral PathConsumed", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68346", " - ALSA: hda: cs35l41: validate and free ACPI mute object", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68348", " - ASoC: tas2781: bound firmware description string parsing", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68450", " - btrfs: free mapping node on duplicate reloc root insert", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68442", " - btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68349", " - wifi: carl9170: fix buffer overflow in rx_stream failover path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68350", " - wifi: carl9170: fix OOB read from off-by-two in TX status handler", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68351", " - wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68352", " - wifi: ath6kl: fix OOB read from firmware IE lengths in connect event", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68353", " - wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68354", " - firewire: net: Fix fragmented datagram reassembly", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68355", " - wifi: ath11k: fix potential buffer underflow in", " ath11k_hal_rx_msdu_list_get()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68356", " - watchdog: airoha: Prevent division by zero when clock frequency is zero", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68357", " - watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68358", " - hwmon: (nzxt-kraken3) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68359", " - hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68443", " - hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68360", " - hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68361", " - hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68362", " - wifi: ath11k: fix NULL pointer dereference in", " ath11k_hal_srng_access_begin", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68363", " - wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware", " request", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68365", " - USB: serial: io_edgeport: cap received transmit credits", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68366", " - usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64583", " - usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before", " teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68368", " - usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68369", " - usb: gadget: printer: fix infinite loop in printer_read()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64584", " - usb: gadget: f_midi: cancel pending IN work before freeing the midi", " object", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68370", " - usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68371", " - usb: musb: omap2430: Do not put borrowed of_node in probe", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68373", " - wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68374", " - usb: core: sysfs: add lock to bos_descriptors_read()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64569", " - mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68376", " - sctp: fix auth_hmacs array size in struct sctp_cookie", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68377", " - net/sched: act_tunnel_key: Defer dst_release to RCU callback", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68378", " - dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68379", " - tcp: fix TIME_WAIT socket reference leak on PSP policy failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68380", " - accel/amdxdna: Fix use-after-free of mm_struct in job scheduler", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64578", " - ksmbd: validate compound request size before reading StructureSize2", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68381", " - ksmbd: pin conn during async oplock break notification", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68384", " - drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68385", " - s390/checksum: Fix csum_partial() without vector facility", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68386", " - bpf, sockmap: Reject unhashed UDP sockets on sockmap update", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68387", " - can: raw: add locking for raw flags bitfield", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68388", " - smb/client: handle overlapping allocated ranges in fallocate", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68389", " - Bluetooth: hci_qca: Clear memdump state on invalid dump size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68391", " - Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68392", " - Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68393", " - Bluetooth: hci_sync: extend conn_hash lookup critical sections", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68394", " - Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64573", " - Bluetooth: qca: fix NVM tag length underflow in TLV parser", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68449", " - ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-", " scanning", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68395", " - ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is", " registered", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68396", " - scsi: core: wake eh reliably when using scsi_schedule_eh", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68397", " - net/iucv: take a reference on the socket found in afiucv_hs_rcv()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64572", " - ipv4: fib: free fib_alias with kfree_rcu() on insert error path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68398", " - ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68400", " - firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset", " calculation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68401", " - firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68402", " - wifi: cfg80211: bound element ID read when checking non-inheritance", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68403", " - wifi: brcmfmac: initialize SDIO data work before cleanup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68405", " - wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68406", " - wifi: cfg80211: validate PMSR FTM preamble range", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68407", " - wifi: nl80211: free RNR data on MBSSID mismatch", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68408", " - wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64571", " - wifi: p54: validate RX frame length in p54_rx_eeprom_readback()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68409", " - wifi: mac80211: defer link RX stats percpu free to RCU", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68410", " - wifi: libertas: fix memory leak in helper_firmware_cb()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64570", " - wifi: mac80211: fix fils_discovery double free on alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64568", " - wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68411", " - wifi: mac80211_hwsim: clamp virtio RX length before skb_put", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68412", " - wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68413", " - wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68414", " - wifi: cfg80211: cancel sched scan results work on unregister", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64579", " - xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64580", " - xfrm6: clear dst.dev on error to avoid double netdev_put in", " xfrm6_fill_dst()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64566", " - xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68415", " - xfrm: clear mode callbacks after failed mode setup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68416", " - mtd: fix double free and WARN_ON in add_mtd_device() error paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68417", " - RDMA/siw: publish QP after initialization", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68418", " - RDMA/irdma: Prevent user-triggered null deref on QP create", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68419", " - RDMA/irdma: Prevent rereg_mr for non-mem regions", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68420", " - xfrm: reject optional IPTFS templates in outbound policies", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68421", " - sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68444", " - firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68422", " - btrfs: fix root leak if its reloc root is unexpected in", " merge_reloc_roots()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64567", " - btrfs: reject free space cache with more entries than pages", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68425", " - IB/mad: Drop unmatched RMPP responses before reassembly", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68426", " - xfrm: fix stale skb->prev after async crypto steals a GSO segment", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64565", " - Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68427", " - gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68428", " - KVM: x86/mmu: Fix use-after-free on vendor module reload", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64562", " - KVM: nVMX: Hide shadow VMCS right after VMCLEAR", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64561", " - KVM: x86: Check for invalid/obsolete root *after* making MMU pages", " available", " * resolute: llvm-21-dev build-depends breaks cross-builds (LP: #2165407)", " - [Packaging] Fix cross-builds", " * Resolute Stable Update v6.18.40, v7.1.5 bugs (LP: #2165040)", " - accel/amdxdna: Allow forcing IOVA-based DMA via module parameter", " - SAUCE: bpf: Add missing NULL argument to zap_page_range_single", " - accel/amdxdna: Return ERR_PTR on dma_alloc_noncoherent failure", " - accel/amdxdna: Fix memory leak in amdxdna_iommu_alloc()", " * [SRU][HPE] Take Intel platform into account for old microcode checks", " (LP: #2161748)", " - x86/microcode: Refactor platform ID enumeration into a helper", " - x86/cpu: Add platform ID to CPU info structure", " - x86/cpu: Add platform ID to CPU matching structure", " - x86/microcode: Add platform mask to Intel microcode \"old\" list", " - x86/microcode: Do not access MSR_IA32_PLATFORM_ID when running as a", " guest", " * ice: E810 interface fails to initialize (ice_init_hw failed: -5) during", " NVM read (LP: #2163508)", " - ice: acquire NVM lock around each flash read", " * WWAN modem unresponsive after freeze on Dell systems with DW5826e", " (LP: #2163214)", " - platform/x86: dell-dw5826e: Add reset driver for DW5826e", " - platform/x86: dell-dw5826e: fix ACPI _DSM function index and bitmask", " usage", " - [Config] Add CONFIG_DELL_DW5826E_RESET=m", " * amdgpu panel self-refresh on dual-gpu laptops causes complete built-in", " panel freeze and severe system instability (LP: #2162904)", " - SAUCE: drm/amdgpu: Do not enter PSR if multiple displays are active", " * linux 7.0: dw9719 VCM never binds, disabling all IPU3 cameras (regression,", " fixed upstream) (LP: #2162045)", " - media: dw9719: Add back the I²C device id table", " * Fix TAS2783 SoundWire amp resume timeout >5s (LP: #2164967)", " - soundwire: Add a helper function to wait for device initialisation", " - ASoC: tas2783: Use new SoundWire enumeration helper", " - soundwire: Move wait for initialisation helper to header", " - ASoC: codecs: tas2783-sdw: Propagate regcache_sync() errors", " - ASoC: tas2783-sdw: drop stale regcache on uninitialized re-attach", " * Linux, Ubuntu, 24.04, System hangs for about 10 seconds when unplug", " external monitor cable on non TBT dock (LP: #2160082)", " - SAUCE: drm/i915/tc: Revert forced DP-alt connected workaround", " * Speakers not detected on HP systems with TI TAS2783 SoundWire amps", " (LP: #2164504)", " - ASoC: sdw_utils: Add missed component_name strings for TI amps", " * [TWL][Desktop] intel_dmc_wait_fw_load() merge to Ubuntu next release", " (LP: #2156316)", " - SAUCE: drm/i915/dmc: fix assert_dmc_loaded WARN during async firmware", " load", " * 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", " * Ethernet adapter unusable after suspend/resume on Advantech systems with", " Intel I226-V (LP: #2163375)", " - igc: fix netdev not re-attached after resume if interface is down", " * ice: fix stale -EBUSY on resume of Intel E810 (LP: #2162803)", " - ice: wait for reset completion in ice_resume()", " * idxd: crash-kernel NULL-pointer Oops in `destroy_workqueue()` breaks kdump", " on Intel DSA/IAA systems (LP: #2163062)", " - SAUCE: dmaengine: idxd: Do not call destroy_workqueue with null idxd->wq", " - SAUCE: dmaengine: idxd: fix duplicate memory frees on initialization", " error path.", " * [HP][ZBook Power 16 G11] Laptop freezed after upgrading the BIOS", " (LP: #2132119)", " - PCI/ASPM: Avoid L0s for Realtek RTS525A", " * Fix noise of audio output on more Dell QCx1255 models after reboot", " (LP: #2163293)", " - ALSA: hda/realtek - Add quirk for Dell Pro QC1255", " * Fix no audio input/output device on Dell WCL Slate platform with", " CirrusLogic audio solution (LP: #2160200)", " - ASoC: SDCA: fix the register to ctl value conversion for Q7.8 format", " - ASoC: SOF: ipc4-control: Use local copy of IPC message for sending", " * Fix no audio output and mute hotkey not working on HP ZBook 8 G2a", " (LP: #2158858)", " - ALSA: hda/realtek: Add inverted LED quirk for HP ZBook 8 G2a", " * Dock ethernet stops working after Thunderbolt dock unplug on Dell systems", " (LP: #2162704)", " - usb: core: port: Deattach Type-C connector on component unbind", " * USB-C alt mode dropped with false firmware bug warning on Dell systems", " (LP: #2162695)", " - Revert \"usb: typec: ucsi: Detect and skip duplicate altmodes from buggy", " firmware\"", " - Revert \"usb: typec: ucsi: Add duplicate detection to nvidia registration", " path\"", " - Revert \"usb: typec: ucsi: yoga_c630: Remove redundant duplicate altmode", " handling\"", " - usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware", " - usb: typec: ucsi: Add duplicate detection to nvidia registration path", " - usb: typec: ucsi: yoga_c630: Remove redundant duplicate altmode handling", " * Resolute update: upstream stable patchset 2026-08-20 (LP: #2164666)", " - crypto: algif_skcipher - force synchronous processing", " - crypto: sun4i-ss - Remove insecure and unused rng_alg", " - [Config] Remove unused CRYPTO_DEV_SUN4I_SS_PRNG", " - media: uvcvideo: Fix deadlock if uvc_status_stop is called from", " async_ctrl.work", " - bpf: Clear delta when clearing reg id for non-{add,sub} ops", " - selftests/bpf: Add tests for delta tracking when src_reg == dst_reg", " - selftests/bpf: Add tests for stale delta leaking through id reassignment", " - ALSA: hda/realtek: Add quirk for TongFang X6xx45xU", " - ALSA: hda: conexant: Remove mic bias threshold override", " - ALSA: hda: Fix cached processing coefficient verbs", " - ALSA: hda/realtek: Fix speakers on Legion Pro 7 16ARX8H with codec SSID", " 17aa:38a7", " - media: uvcvideo: Use hw timestaming if the clock buffer is full", " - media: uvcvideo: Avoid partial metadata buffers", " - media: uvcvideo: Fix buffer sequence in frame gaps", " - media: uvcvideo: Fix dev_sof filtering in hw timestamp", " - media: uvcvideo: Do not add clock samples with small sof delta", " - media: uvcvideo: Relax the constrains for interpolating the hw clock", " - 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: max310x: implement gpio_chip::get_direction()", " - serial: 8250_omap: clear rx_running on zero-length DMA completes", " - rxrpc: rxrpc_verify_data ensure rx_dec_buffer alloc", " - rxrpc: Fix socket notification race", " - rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)", " - rxrpc: Fix potential infinite loop in rxrpc_recvmsg()", " - rxrpc: Fix rxrpc_rotate_tx_rotate() to check there's something to rotate", " - rxrpc: Fix oob challenge leak in cleanup after notification failure", " - rxrpc: Fix ACKALL packet handling", " - rxrpc: Fix the reception of a reply packet before data transmission", " - rxrpc: Fix leak of connection from OOB challenge", " - afs: fix NULL pointer dereference in afs_get_tree()", " - afs: handle CB.InitCallBackState3 requests without a server record", " - afs: Fix uncancelled rxrpc OOB message handler", " - fbcon: fix NULL pointer dereference for a console without vc_data", " - fbcon: Use correct type for vc_resize() return value", " - openrisc: mm: Fix section mismatch between map_page and __set_fixmap", " - clocksource/drivers/sun5i: Handle error returns from", " devm_reset_control_get_optional_exclusive()", " - accel/amdxdna: Fix leak when pinning ubuf pages", " - drm/rockchip: dw_dp: Switch to drmm_kzalloc()", " - drm/rockchip: dw_dp: Fix null-ptr-deref in dw_dp_remove()", " - drm/rockchip: Test for imported buffers with drm_gem_is_imported()", " - drm/tidss: Drop extra drm_mode_config_reset() call", " - drm/gpusvm: Reject VMAs with VM_IO or VM_PFNMAP when creating SVM ranges", " - drm/gpuvm: Do not prepare NULL objects", " - 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", " - selftests/bpf: Fix off-by-one in bpf_cpumask_populate related selftest", " - dt-bindings: timer: Remove sifive,fine-ctr-bits property", " - drm/amd/pm: remove trailing semicolon from AMDGPU_PM_POLICY_ATTR macro", " - selftests/bpf: Use local type for flow_offload_tuple_rhash in", " xdp_flowtable", " - selftests/bpf: Use local type for bpf_fou_encap in test_tunnel_kern", " - Documentation: proc: fix section numbering in table of contents", " - arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Cobra", " - arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S", " - arm64: dts: qcom: ipq5424: Fix USB simple_bus_reg warnings", " - arm64: dts: qcom: sc8180x: Fix phy simple_bus_reg warning", " - 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: fix wrong pci_get_drvdata type in AER handlers", " - wifi: rtw88: fix wrong pci_get_drvdata type in AER handlers", " - wifi: rtw89: Correct data type for scan index to avoid infinite loop", " - wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA", " buffer", " - wifi: rtw89: add bounds check on firmware mac_id in link lookup", " - kconfig: fix potential NULL pointer dereference in conf_askvalue", " - soc: xilinx: Shutdown and free rx mailbox channel", " - pinctrl: mediatek: eint: Drop base from mtk_eint_chip_write_mask()", " - wifi: ath9k: fix OOB access from firmware tx status queue ID", " - ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint", " - Documentation/rv: Replace stale website link", " - 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", " - memory: tegra: Wire up system sleep PM ops", " - crypto: qat - fix heartbeat error injection", " - lib/vsprintf: Fix to check field_width and precision", " - dts: spacemit: set console baud rate on bpif3", " - pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path", " - dt-bindings: vendor-prefixes: Add Displaytech Ltd.", " - drm/gpuvm: take refcount on DRM device", " - drm/panel: Clean up S6E3HA2 config dependencies and fill help text", " - ARM: dts: rockchip: Add #{address,size}-cells to Chromium-based", " /firmware", " - arm64: dts: rockchip: Add #{address,size}-cells to Chromium-based", " /firmware", " - arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc", " - arm64: dts: imx8x-colibri: Correct SODIMM PAD settings", " - Revert \"arm64: dts: imx8mm-kontron: Add support for reading SD_VSEL", " signal\"", " - Revert \"arm64: dts: imx8mp-kontron: Add support for reading SD_VSEL", " signal\"", " - drm: renesas: rz-du: mipi_dsi: Fix return path on error", " - alarmtimer: Remove stale return description from alarm_handle_timer()", " - OPP: Fix race between OPP addition and lookup", " - crypto: ccp - Reverse the cleanup order in psp_dev_destroy()", " - crypto: ccp - Fix snp_filter_reserved_mem_regions() off-by-one", " - 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", " - ARM: multi_v7_defconfig: Correct QCOM_RPMH and QCOM_RPMHPD", " - nilfs2: fix backing_dev_info reference leak", " - media: qcom: camss: vfe: fix PIX subdev naming on VFE lite", " - media: iris: scale MMCX power domain on SM8250", " - media: venus: scale MMCX power domain on SM8250", " - iommu/amd: Fix a stale comment about which legacy mode is user visible", " - soc: mediatek: mtk-mmsys: Restore MT8167 routing masks lost during merge", " - bpf: fix crash in bpf_[set|remove]_dentry_xattr for negative dentries", " - uaccess: fix ignored_trailing logic in copy_struct_to_user()", " - arm64: dts: mediatek: mt8192-asurada: Move PCIe DMA bounce buffer to", " host", " - rust: alloc: fix `Vec::extend_with` SAFETY comment", " - clk: scmi: Fix clock rate rounding", " - arm64: dts: qcom: kodiak: Fix ICE reg size", " - arm64: dts: qcom: sm8450: Fix ICE reg size", " - drm/hisilicon/hibmc: add updating link cap in DP detect()", " - drm/hisilicon/hibmc: fix no showing when no connectors connected", " - drm/hisilicon/hibmc: move display contrl config to hibmc_probe()", " - 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()", " - scsi: hisi_sas: Add slave_destroy interface for v3 hw", " - 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)", " - IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier", " - RDMA/hns: Fix arithmetic overflow in calc_hem_config()", " - RDMA/mlx5: Fix UMR XLT cleanup on ODP populate failure", " - RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference", " - RDMA/hns: Initialize seqfile before creating file", " - drm/syncobj: Fix memory leak in drm_syncobj_find_fence()", " - selftests/bpf: Reject unsupported -k option in vmtest.sh", " - selftests/bpf: Fix test for refinement of single-value tnum", " - iommu/arm-smmu-qcom: Fix fastrpc compatible string in ACTLR client match", " table", " - selftests/mm: Fix resv_sz when parsing arm64 signal frame", " - firmware: arm_ffa: Honor partition info descriptor size", " - arm64: dts: imx8dxl-evk: Remove unnecessary PCIe EP properties", " - arm64: dts: imx8qxp-mek: Remove unnecessary PCIe EP vpcie-supply", " - arm64: dts: imx95-19x19-evk: Fix PCIe EP vpcie-supply", " - media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()", " - media: atomisp: gc2235: fix UAF and memory leak", " - staging: media: atomisp: fix loop shadowing in ia_css_stream_destroy()", " - riscv: dts: spacemit: set console baud rate on Milk-V Jupiter", " - firmware: smccc: Fix Arm SMCCC SOC_ID name call", " - firmware: arm_scmi: Read sensor config as 32-bit value", " - sysfs: clamp show() return value in sysfs_kf_read()", " - bitops: use common function parameter names", " - regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions", " - tools/nolibc: getopt: Fix potential out of bounds access", " - nilfs2: Fix return in nilfs_mkdir", " - net/sched: sch_drr: annotate data-races around cl->deficit", " - media: rockchip: rga: fix too small buffer size", " - firmware: arm_scmi: Fix OOB in scmi_power_name_get()", " - arm64: dts: qcom: lemans: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: monaco: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sc7180: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: kodiak: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8550: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8750: Add power-domain and iface clk for ice node", " - tracing: Bound synthetic-field strings with seq_buf", " - arm64: dts: qcom: lemans: Add eDP ref clock for eDP PHYs", " - writeback: drop now-unnecessary rcu_barrier() in", " cgroup_writeback_umount()", " - kernfs: fix suspicious RCU usage in kernfs_put()", " - 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", " - Revert \"treewide: Fix probing of devices in DT overlays\"", " - of: dynamic: Fix overlayed devices not probing because of fw_devlink", " - crypto: eip93 - fix reset ring register definition", " - cpufreq: Documentation: fix sampling_down_factor range", " - cpufreq: conservative: Simplify frequency limit handling", " - pwm: imx27: Fix variable truncation in .apply()", " - RDMA/mana_ib: Use ib_get_eth_speed for reporting port speed", " - bus: sunxi-rsb: Always check register address validity", " - pinctrl: spacemit: fix NULL check in spacemit_pin_set_config", " - 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/hns: Fix log flood after cmd_mbox failure", " - RDMA/counter: Fix incorrect port index in rdma_counter_init() error", " cleanup", " - pinctrl: meson: amlogic-a4: fix gpio output glitch", " - PM: sleep: Use complete() in device_pm_sleep_init()", " - 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", " - driver core: Fix missing jiffies conversion in", " deferred_probe_extend_timeout()", " - driver core: Guard deferred probe timeout extension with", " delayed_work_pending()", " - mtd: spi-nor: debugfs: Fix the flags list", " - mtd: spi-nor: Drop duplicate Kconfig dependency", " - ALSA: xen-front: Reset event channel state on stream clear", " - ALSA: xen-front: Connect event channel after stream prepare", " - ALSA: seq: oss: Fix UAF at handling events with embedded SysEx data", " - ALSA: seq: midi: Serialize output teardown with event_input", " - selftests: Fix Makefile target for nsfs", " - pinctrl: nuvoton: ma35d1: fix MFP register offset and pin table", " - pinctrl: cs42l43: Fix leaked pm reference on error path", " - pinctrl: cs42l43: Fix polarity on debounce", " - init/initramfs_test: wait_for_initramfs() before running", " - nvmet-tcp: fix page fragment cache leak in error path", " - nvmet-tcp: check return value of nvmet_tcp_set_queue_sock", " - nvme-pci: fix out-of-bounds access in nvme_setup_descriptor_pools", " - 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", " - iommu/amd: Fix premature break in init_iommu_one()", " - rtla/actions: Restore continue flag in actions_perform()", " - 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", " - bpftool: Fix typo in struct_ops map FD generation for light skeleton", " - libbpf: Fix UAF in strset__add_str()", " - ARM: tegra: Add #{address,size}-cells to Chromium-based /firmware", " - arm64: tegra: Add #{address,size}-cells to Chromium-based /firmware", " - 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", " - crypto: inside-secure/eip93 - Add check for devm_request_threaded_irq", " - crypto: tegra - Fix dma_free_coherent size error", " - crypto: tegra - Return ENOMEM when input buffer allocation fails for ccm", " - sched/deadline: Reject debugfs dl_server writes for offline CPUs", " - drm/msm/dp: fix HPD state status bit shift value", " - drm/msm/dp: Fix the ISR_* enum values", " - EDAC/igen6: Fix call trace due to missing release()", " - EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in", " skx_get_dimm_info", " - arm64: dts: st: Fix SAI addresses on stm32mp251", " - RDMA/umem: Add ib_umem_is_contiguous() stub for", " !CONFIG_INFINIBAND_USER_MEM", " - RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe", " - RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path", " - Revert \"media: venus: hfi_platform: Correct supported codecs for sc7280\"", " - 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", " - amba: use generic driver_override infrastructure", " - cdx: use generic driver_override infrastructure", " - Drivers: hv: vmbus: use generic driver_override infrastructure", " - rpmsg: use generic driver_override infrastructure", " - raid1: fix nr_pending leak in REQ_ATOMIC bad-block error path", " - bpf: fix BPF_PROG_QUERY OOB write and cgroup backward compat", " - selftests/bpf: add verification for BPF_PROG_QUERY attr size boundaries", " - libbpf: Skip hash computation when loader generation failed", " - libbpf: Skip endianness swap when loader generation failed", " - ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data", " writeback", " - spi: atmel: fix DMA channel and bounce buffer leaks", " - ASoC: rsnd: Fix RSND_SOC_MASK width to single nibble", " - NFSD: Fix delegation reference leak in nfsd4_revoke_states", " - ARM: imx3: Fix CCM node reference leak", " - HID: wiimote: Fix table layout and whitespace errors", " - wifi: ath12k: fix incorrect HT/VHT/HE/EHT MCS reporting in monitor mode", " - wifi: ath12k: fix NULL deref in change_sta_links for unready link", " - ata: libata: Fix ata_exec_internal()", " - ARM: imx31: Fix IIM mapping leak in revision check", " - x86/cpu: Keep the PROCESSOR_SELECT menu together", " - nvdimm/btt: Handle preemption in BTT lane acquisition", " - scsi: Revert \"scsi: Fix sas_user_scan() to handle wildcard and multi-", " channel scans\"", " - bpf: Reject exclusive maps as inner maps in map-in-map", " - libbpf: Reject non-exclusive metadata maps in the signed loader", " - libbpf: Skip initial_value override on signed loaders", " - libbpf: Skip max_entries override on signed loaders", " - 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", " - driver core: Use system_percpu_wq instead of system_wq", " - bpf: Reject exclusive maps for bpf_map_elem iterators", " - tick/sched: Fix TOCTOU in nohz idle time fetch", " - lib/test_meminit: use && for bools", " - riscv: dts: sophgo: sg2044: use hex for CPU unit address", " - riscv: dts: sophgo: sg2042: use hex for CPU unit address", " - configfs_lookup(): don't leave ->s_dentry dangling on failure", " - lockdep/selftests: Restore migrate_disable() state on PREEMPT_RT", " - lockdep/selftests: Restore sched_rt_mutex state on PREEMPT_RT", " - ext4: fix fast commit wait/wake bit mapping on 64-bit", " - drm/amdgpu: set sub_block_index for mca ras sub-blocks", " - bpftool: Use libbpf error code for flow dissector query", " - vhost: fix vhost_get_avail_idx for a non empty ring", " - iommu/vt-d: Fix RB-tree corruption in probe error path", " - perf/x86/amd/core: Always use the NMI latency mitigation", " - perf/x86/intel/uncore: Fix discovery unit lookup for multi-die systems", " - perf/x86/amd/uncore: Use Node ID to identify DF and UMC domains", " - xfrm: fix NAT-related field inheritance in SA migration", " - cxl/fwctl: Fix __fortify_panic", " - drm/amdkfd: always resume_all after suspend_all", " - of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array()", " fails", " - ocfs2: rebase copied fsdlm LVB pointers in locking_state", " - lib: kunit_iov_iter: repeatedly call alloc_pages_bulk()", " - 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: 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", " - netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock", " - ALSA: usb-audio: qcom: Initialize offload control return value", " - x86/cpu: Remove obsolete aperfmperf_get_khz() declaration", " - netfilter: conntrack: revert ct extension genid infrastructure", " - netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper", " is pptp", " - RDMA/hfi1: Open-code rvt_set_ibdev_name()", " - IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()", " - ALSA: hda: fix Kconfig dependency of HD Audio PCI", " - RDMA/irdma: Fix OOB read during CQ MR registration", " - RDMA/irdma: Initialize iwmr->access during MR registration", " - arm64: dts: imx8mp-kontron: Reduce EERAM SPI clock frequency", " - arm64: dts: imx95: Correct PCIe outbound address space configuration", " - arm64: dts: lx2162a-clearfog: use rev2 SoC dtsi", " - arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio codec as", " well", " - arm64: dts: imx8mp-kontron: Fix GPIO for display power switch", " - bpf: Clear rb node linkage when freeing bpf_rb_root", " - bpf: Check tail zero of bpf_map_info", " - 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: cpu_ops: Change return value type of cpu_is_stopped() to bool", " - riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe", " - ALSA: seq: Clear variable event pointer on read", " - bpf: Fix NMI/tracepoint re-entry deadlock on lru locks", " - kunit:tool: Don't write to stdout when it should be disabled", " - powerpc/8xx: implement get_direction() in cpm1", " - bpf: Fix NULL pointer dereference in bpf_task_from_vpid()", " - ACPI: IPMI: Fix message kref handling on dead device", " - cpufreq: Documentation: fix conservative governor freq_step description", " - thermal: testing: reject missing command arguments", " - btrfs: don't force DIO writes to be serialized", " - IB/mlx5: Don't take the rereg_mr fallback without a new translation", " - IB/mlx5: Properly support implicit ODP rereg_mr", " - IB/mlx5: Remove unused mkc bits in mlx5r_umr_update_mr_page_shift()", " - IB/mlx5: Pull the pdn out of the depths of the umr machinery", " - IB/mlx5: Don't mangle the mr->pd inside the rereg callback", " - spi: ep93xx: fix double-free of zeropage on DMA setup failure", " - ASoC: amd: acp-sdw-legacy: Bound DAI link iteration", " - ASoC: amd: acp-sdw-sof: Bound DAI link iteration", " - firmware_loader: Fix recursive lock in device_cache_fw_images()", " - configfs: fix lockless traversals of ->s_children", " - watchdog: unregister PM notifier on watchdog unregister", " - pinctrl: qcom: Fix resolving register base address from device node", " - 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", " - ARM: configs: Drop duplicated CONFIG_EXT4_FS", " - wifi: mt76: mt7925: clean up DMA on probe failure", " - wifi: mt76: use kfree_rcu for offchannel link in mt76_put_vif_phy_link", " - wifi: mt76: mt7996: add missing max_remain_on_channel_duration", " - wifi: mt76: mt7925: fix stale pointer comparisons in change_vif_links", " - wifi: mt76: mt7925: keep TX BA state in the primary WCID", " - wifi: mt76: mt792x: skip MLD header rewrite for 802.3 encap TX", " - wifi: mt76: mt7925: validate skb length in testmode query", " - wifi: mt76: mt7996: Fix possible token leak in mt7996_tx_prepare_skb()", " - wifi: mt76: mt7996: Fix possible NULL pointer dereference in", " mt7996_mac_write_txwi_80211()", " - wifi: mt76: mt7996: fix reading zeroed info->control.flags after", " mt76_tx_status_skb_add()", " - wifi: mt76: mt7996: limit work in set_bitrate_mask", " - 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", " - wifi: mt76: mt7925: fix potential tx_retries underflow", " - wifi: mt76: mt7996: fix potential tx_retries underflow", " - btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()", " - ALSA: aloop: Drop superfluous break", " - gpio: mt7621: fix interrupt banks mapping on gpio chips", " - wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is", " reported", " - fbdev: sm501fb: Fix buffer errors in OF binding code", " - vfs: add FS_USERNS_DELEGATABLE flag and set it for NFS", " - hwmon: (it87) Clamp negative values to zero in set_fan()", " - btrfs: zoned: don't account data relocation space-info in statfs free", " space", " - Revert \"btrfs: fix the file offset calculation inside", " btrfs_decompress_buf2page()\"", " - btrfs: zoned: always set max_active_zones for zoned devices", " - btrfs: annotate lockless read of defrag_bytes in should_nocow()", " - btrfs: fix deadlock cloning inline extent when using flushoncommit", " - igc: skip RX timestamp header for frame preemption verification", " - ASoC: sma1307: Fix uevent string leaks in fault worker", " - IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified", " - NFSD: Handle layout stid in nfsd4_drop_revoked_stid()", " - 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", " - virtio: rtc: tear down old virtqueues before restore", " - virtio_console: read size from config space during device init", " - vduse: Requeue failed read to send_list head", " - tools/virtio: check mmap return value in vringh_test", " - vdpa/octeon_ep: Fix PF->VF mailbox data address calculation", " - vdpa/octeon_ep: fix IRQ-to-ring mapping in interrupt handler", " - ASoC: cs35l56: Fix missing calls to wm_adsp2_remove()", " - ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend fails", " - ext4: fix ERR_PTR(0) in ext4_mkdir()", " - tools: missed broadcast_neigh if_link uapi header", " - netlink: specs: rt-link: missed broadcast-neigh", " - bonding: 3ad: add lacp_strict configuration knob", " - bonding: 3ad: fix carrier when no usable slaves", " - 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()", " - vfio/qat: fix f_pos race in qat_vf_resume_write()", " - bpf: Tighten cgroup storage cookie checks for prog arrays", " - pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag", " - pinctrl: airoha: an7581: add missed gpio32 pin group", " - pinctrl: airoha: an7581: fix misprint in gpio19 pinconf", " - arm64: dts: allwinner: a523: Add missing GPIO interrupt", " - ASoC: cs35l56: Fix possible uninitialized value in", " cs35l56_spi_system_reset()", " - s390/process: Fix kernel thread function pointer type", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for", " non-serdev device", " - Bluetooth: eir: Fix stack OOB write when prepending the Flags AD", " - Bluetooth: hci_event: fix simultaneous discovery stuck in FINDING", " - Bluetooth: hci_core: Fix UAF in hci_unregister_dev()", " - Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path", " - Bluetooth: hci: validate codec capability element length", " - Bluetooth: vhci: validate devcoredump state before side effects", " - fs: efs: remove unneeded debug prints", " - RDMA/mlx5: Remove DCT restrack tracking", " - 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: SOF: Intel: hda-sdw-bpt: select SND_SOF_SOF_HDA_SDW_BPT properly", " - 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: dsa: qca8k: fix led devicename when using external mdio bus", " - 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", " - net: pfcp: allocate per-cpu tstats for PFCP netdevs", " - 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: Unregister cxl_acpi in cxl_test_init() error path", " - 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", " - ALSA: usb-audio: qcom: Guard sideband endpoint removal", " - ALSA: seq: Fix kernel heap address leak in bounce_error_event()", " - spi: xilinx: use FIFO occupancy register to determine buffer size", " - iommu: Avoid copying the user array twice in the full-array copy helper", " - 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", " - virtio_net: do not allow tunnel csum offload for non GSO packets", " - net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net/sched: sch_dualpi2: 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", " - net: watchdog: fix refcount tracking races", " - net: ethernet: mtk_wed: fix loading WO firmware for MT7986", " - net/sched: sch_dualpi2: Add missing module alias", " - bpf: Run generic devmap egress prog on private skb", " - net/mlx5: Check max_macs devlink param value against max capability", " - bpf: Fix setting retval to -EPERM for cgroup hooks not returning errno", " - octeontx2-af: npc: Fix size of entry2cntr_map", " - net: ethernet: mtk_wed: debugfs: correct index in wed_amsdu_show()", " - net: wwan: t7xx: check skb_clone in control TX", " - 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", " - net: bcmgenet: Use weighted round-robin TX DMA arbitration", " - net: airoha: Fix register index for Tx-fwd counter configuration", " - net: airoha: Fix debugfs new-tuple display for IPv4 ROUTE entries", " - kcm: use WRITE_ONCE() when changing lower socket callbacks", " - ALSA: seq: oss: Serialize readq reset state with q->lock", " - ALSA: seq: avoid stale FIFO cells during resize", " - 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: Fix typo in verify_umulti_link_info", " - selftests/bpf: Initialize operation name before use", " - bpf: Fix bpf_get/setsockopt to tos for ipv4-mapped ipv6 socket", " - udf: fix nls leak on udf_fill_super() failure", " - bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()", " - net: remove addr_len argument of recvmsg() handlers", " - sockmap: Fix use-after-free in udp_bpf_recvmsg()", " - 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", " - tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)", " - net: airoha: Fix always-true condition in PPE1 queue reservation loop", " - net: ethernet: oa_tc6: Remove FCS size in RX frame", " - ionic: Fix check in ionic_get_link_ext_stats", " - RDMA/bnxt_re: Free SRQ toggle page after firmware teardown", " - RDMA/bnxt_re: Avoid displaying the kernel pointer", " - RDMA/bnxt_re: Fail DBR related page allocation UAPIs if the feature is", " disabled", " - ksmbd: fix use-after-free in same_client_has_lease()", " - mfd: rsmu: Fix page register setup", " - mfd: cs42l43: Sanity check firmware size", " - ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write", " - 9p: avoid returning ERR_PTR(0) from mkdir operations", " - eventpoll: rename ep_remove_safe() back to ep_remove()", " - eventpoll: expand top-of-file overview / locking doc", " - eventpoll: rename attach_epitem() to ep_attach_file()", " - 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", " - i3c: master: svc: Fix missed IBI after false SLVSTART on NPCM845", " - staging: nvec: fix use-after-free in nvec_rx_completed()", " - perf debuginfo: Fix libdw API contract violations", " - coresight: cti: Fix DT filter signals silently ignored", " - soundwire: don't program SDW_SCP_BUSCLOCK_SCALE on a unattached", " Peripheral", " - soundwire: fix bug in sdw_add_element_group_count found by syzkaller", " - coresight: ete: Always save state on power down", " - 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", " - perf sched: Add missing mmap2 handler in timehist", " - PCI: loongson: Do not ignore downstream devices on external bridges", " - rust: alloc: fix assert in `Vec::reserve` doc test", " - bus: mhi: ep: Fix potential deadlock in mhi_ep_reset_worker()", " - coresight: fix missing error code when trace ID is invalid", " - clk: qcom: cmnpll: Account for reference clock divider", " - phy: phy-can-transceiver: Check driver match and driver data against", " NULL", " - perf pmu: Skip test on Arm64 when #slots is zero", " - clk: at91: sam9x7: Fix gmac_gclk clock definition", " - soundwire: intel_ace2x: release bpt_stream when close it", " - coresight: Fix source not disabled on idr_alloc_u32 failure", " - mailbox: mpfs: fix check for syscon presence in mpfs_mbox_inbox_isr()", " - mailbox: mtk-adsp: fix UAF during device teardown", " - PCI: dwc: Fix signedness bug in fault injection test code", " - perf build-id: Fix off-by-one bug when printing kernel/module build-id", " - 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", " - perf test amd ibs: Fix incorrect kernel version check", " - gpib: Fix inappropriate ioctl error return", " - char: tlclk: fix use-after-free in tlclk_cleanup()", " - gpib: fix double decrement of descriptor_busy in command_ioctl()", " - clk: renesas: rzg2l: Rename iterator in for_each_mod_clock() to avoid", " shadowing", " - powerpc tools perf: Initialize error code in auxtrace_record_init", " function", " - PCI: qcom: Disable ASPM L0s for SA8775P", " - perf header: Sanity check HEADER_EVENT_DESC attr.size before swap", " - 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", " - drm/amd/display: Add missing kdoc for ALLM parameters", " - thunderbolt: debugfs: Fix margining error counter buffer leak", " - dmaengine: imx-sdma: Refine spba bus searching in probe", " - dt-bindings: dma: nvidia,tegra186-gpc-dma: Make reset optional", " - perf: Fix off-by-one stack buffer overflow in kallsyms__parse()", " - perf annotate: Fix crashes on empty annotate windows", " - perf tools: Guard test_bit from out-of-bounds sample CPU", " - perf sched: Fix thread reference leak in latency_switch_event", " - perf tools: Add bounds check to cpu__get_node()", " - perf sched: Cap max_cpu at MAX_CPUS in timehist sample processing", " - perf sched: Fix register_pid() overflow, strcpy, and BUG_ON", " - perf mmap: Guard cpu__get_node() return in aio_bind()", " - perf stat: Bounds-check CPU index in topology aggregation callbacks", " - perf c2c: Bounds-check CPU and node IDs before bitmap and array access", " - perf c2c: Bounds-check CPU IDs in setup_nodes() topology loop", " - perf sched: Clean up idle_threads entry on init failure", " - perf sched: Use thread__put() in free_idle_threads()", " - perf sched: Replace BUG_ON and add NULL checks in replay event helpers", " - perf mmap: Fix NULL deref in aio cleanup on alloc failure", " - perf stat: Introduce perf_env__get_cpu_topology() to guard NULL env->cpu", " - perf c2c: Fix use-after-free in he__get_c2c_hists() error path", " - perf timechart: Fix cpu2y() OOB read on untrusted CPU index", " - perf tools: Fix int16_t truncation of max_cpu_num in set_max_cpu_num()", " - dt-bindings: clock: qcom: Add X1P42100 camera clock controller", " - clk: qcom: camcc-x1e80100: Add support for camera QDSS debug clocks", " - mshv: add bounds check on vp_index in mshv_intercept_isr()", " - dmaengine: qcom: gpi: set DMA_PRIVATE capability", " - dmaengine: Fix possible use after free", " - dmaengine: dma-axi-dmac: Properly free struct axi_dmac_desc", " - dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor", " - clk: qcom: a53: Corrected frequency multiplier for 1152MHz", " - sunrpc: Fix error handling in rpc_sysfs_xprt_switch_add_xprt_store()", " - pNFS/filelayout: fix cheking if a layout is striped", " - 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", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in", " pg_get_mirror_count_write", " - PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro", " - pwm: rzg2l-gpt: Add missing newlines to dev_err_probe() messages", " - PCI: meson: Propagate devm_add_action_or_reset() failure", " - PCI: meson: Add missing remove callback", " - fs/ntfs3: resize log->one_page_buf when adopting on-disk page size", " - platform/x86/intel/vsec: Decouple add/link helpers from PCI", " - platform/x86/intel/vsec: Switch exported helpers from pci_dev to device", " - platform/x86/intel/vsec: Return real error codes from registration path", " - platform/x86/intel/vsec: Restore BAR fallback for header walk", " - perf tools: Fix get_max_num() size_t underflow on empty sysfs file", " - perf tools: Use scnprintf() in cpu_map__snprint() to prevent overflow", " - perf tools: Use perf_env__get_cpu_topology() in machine__resolve()", " - PCI: rcar-host: Remove unused LIST_HEAD(res)", " - perf sched: Bounds-check prio before test_bit() in timehist", " - perf sched: Fix idle-hist callchain display using wrong rb_first variant", " - perf bpf: Use scnprintf() in snprintf_hex() and", " synthesize_bpf_prog_name()", " - perf hists: Fix snprintf() in hists__scnprintf_title() UID filter path", " - xprtrdma: Fix ep kref imbalance on ADDR_CHANGE", " - xprtrdma: Initialize re_id before removal registration", " - xprtrdma: Check frwr_wp_create() during connect", " - xprtrdma: Document and assert reply-handler invariants", " - xprtrdma: Resize reply buffers before reposting receives", " - xprtrdma: Sanitize the reply credit grant after parsing", " - xprtrdma: Repost Receive buffers for malformed replies", " - xprtrdma: Return sendctx slot after Send preparation failure", " - perf s390: Fix TEXTREL in Python extension by compiling as PIC", " - perf cs-etm: Queue context packets for frontend", " - perf pmu: Fix pmu_id() heap underwrite on empty identifier file", " - perf pmu: Fix perf_pmu__parse_scale/unit() OOB access on empty sysfs", " file", " - tools lib api: Fix missing null termination in filename__read_int/ull()", " - perf symbols: Fix signed overflow in sysfs__read_build_id() size check", " - perf symbols: Bounds-check .gnu_debuglink section data", " - perf intel-pt: Fix snprintf size tracking bug in insn decoder", " - perf tools: Fix thread__set_comm_from_proc() on empty comm file", " - perf hwmon: Fix off-by-one null termination on sysfs reads", " - perf hwmon: Use scnprintf() in hwmon_pmu__for_each_event()", " - perf hwmon: Fix parse_hwmon_filename() strlcpy buffer overflow", " - perf symbols: Bounds-check descsz in sysfs__read_build_id() GNU fallback", " - perf hwmon: Guard label read against empty or failed reads", " - perf tools: Use snprintf() in dso__read_running_kernel_build_id()", " - tools lib api: Fix filename__write_int() writing uninitialized stack", " data", " - tools lib api: Fix mount_overload() snprintf truncation and toupper", " range", " - perf bpf: Add NULL check for btf__type_by_id() in", " synthesize_bpf_prog_name()", " - perf bpf: Fix map data leak in bpf_metadata_create() on alloc failure", " - perf bpf: Fix metadata leak in perf_env__add_bpf_info() on duplicate", " insert", " - perf symbols: Add bounds checks to elf_read_build_id() note iteration", " - perf symbols: Add bounds checks to read_build_id() note iteration in", " minimal build", " - dt-bindings: phy: sc8280xp-qmp-pcie: Disallow bifurcation register on", " Purwa", " - PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()", " - PCI: mediatek: Use actual physical address instead of virt_to_phys()", " - phy: freescale: phy-fsl-imx8qm-lvds-phy: Fix missing", " pm_runtime_disable() on probe error path", " - PCI: dwc: Avoid dwc_pcie_rasdes_debugfs_deinit() NULL dereference when", " no RAS DES capability", " - Revert \"PCI/MSI: Unmap MSI-X region on error\"", " - apparmor: fix shadowing of plabel that prevents cache from being updated", " - apparmor: fix race in unix socket mediation when peer_path is used", " - apparmor: fix refcount leak when updating the sk_ctx", " - security/apparmor/apparmorfs.c: conditionally compile", " get_loaddata_common_ref()", " - apparmor: check label build before no_new_privs test", " - apparmor: aa_label_alloc use aa_label_free on alloc failure", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [41/57]: apparmor-next 7.1:", " apparmor: fix rawdata_f_data implicit flex array\"", " - apparmor: fix rawdata_f_data implicit flex array", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [38/57]: apparmor-next 7.1:", " apparmor: grab ns lock and refresh when looking up changehat child", " profiles\"", " - apparmor: grab ns lock and refresh when looking up changehat child", " profiles", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [44/57]: apparmor-next 7.1:", " apparmor: fix potential UAF in aa_replace_profiles\"", " - apparmor: fix potential UAF in aa_replace_profiles", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor: fix NULL pointer dereference in", " unpack_pdb\"", " - apparmor: fix NULL pointer dereference in unpack_pdb", " - apparmor: remove or add symlinks to rawdata according to export_binary", " - apparmor: Fix return in ns_mkdir_op", " - apparmor: fail policy unpack on accept2 allocation failure", " - apparmor: aa_getprocattr free procattr leak on format failure", " - apparmor: put secmark label after secid lookup", " - apparmor: don't audit files pointing to aa_null.dentry", " - apparmor: fix uninitialised pointer passed to", " audit_log_untrustedstring()", " - i3c: mipi-i3c-hci: Preserve RUN bit when aborting DMA ring", " - i3c: master: Make hot-join workqueue freezable to block hot-join during", " suspend", " - i3c: master: Move rstdaa error suppression", " - i3c: master: Consolidate Hot-Join DAA work in the core", " - i3c: master: Ensure Hot-Join operations are stopped on shutdown", " - i3c: master: Defer new-device registration out of DAA caller context", " - i3c: master: Prevent reuse of dynamic address on device add failure", " - apparmor: fix label can not be immediately before a declaration", " - accel/ivpu: fix HWS command queue leak on registration failure", " - sparc: led: avoid trimming a newline from empty writes", " - perf symbols: Fix bswap copy-paste error for 32-bit ELF p_filesz", " - perf symbols: Validate p_filesz before use in filename__read_build_id()", " - perf symbols: Break infinite loop on zero-filled notes in", " sysfs__read_build_id()", " - perf tools: Add O_CLOEXEC to open() calls in DSO and ELF code", " - perf tools: Fix uninitialized pathname on uncompressed fallback in", " filename__decompress()", " - perf dso: Fix heap overflow in dso__get_filename() on decompressed path", " - perf dso: Set error code when open() fails on uncompressed fallback path", " - perf tools: Use snprintf() for root_dir path construction", " - perf hwmon: Fix fd check to accept fd 0 in hwmon_pmu__describe_items()", " - perf sched: Replace (void*)1 sentinel with proper runtime allocation", " - perf bpf: Validate func_info_rec_size and sub_id in", " synthesize_bpf_prog_name()", " - perf bpf: Reject oversized BPF metadata events that truncate header.size", " - perf bpf: Bounds-check array offsets in bpil_offs_to_addr()", " - perf cs-etm: Reject CPU IDs that would overflow signed comparison", " - gpio: mlxbf3: fail probe if gpiochip registration fails", " - drm/i915: clear CRTC color blob pointers after dropping refs", " - drm/xe: Fix wa_oob codegen recipe for external module builds", " - spi: dw: fix wrong BAUDR setting after resume", " - i3c: master: Update dev_nack_retry_count under maintenance lock", " - i3c: master: Add missing runtime PM get in dev_nack_retry_count_store()", " - ALSA: usb-audio: qcom: Free sideband sg_table objects", " - xfrm: annotate data-races around xfrm_policy_count[] and", " xfrm_policy_default[]", " - xfrm: validate selector family and prefixlen during match", " - perf machine: Use snprintf() for guestmount path construction", " - perf cs-etm: Validate num_cpu before metadata allocation", " - perf cs-etm: Require full global header in auxtrace_info size check", " - perf cs-etm: Bounds-check CPU in cs_etm__get_queue()", " - perf bpf: Validate array presence before casting BPF prog info pointers", " - perf dso: Set standard errno on decompression failure", " - ASoC: tlv320aic3x: restrict CLKDIV bypass Q values in dual-rate mode", " - drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free", " - drm/amd/display: Fix mem_type change detection for async flips", " - drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm", " - drm/amdgpu: initialize irq.lock spinlock earlier", " - 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", " - ALSA: usb-audio: qcom: reject stream disable with no active interface", " - ALSA: usb-audio: qcom: clear opened when stream enable fails", " - 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()", " - dpaa2-switch: fix VLAN upper check not rejecting bridge join", " - devlink: Fix parent ref leak in devl_rate_node_create()", " - devlink: Fix parent ref leak on tc-bw failure", " - net: airoha: fix foe_check_time allocation size", " - net: macb: add TX stall timeout callback to recover from lost TSTART", " write", " - flow_dissector: check device type before reading ETH_ADDRS", " - selftests: vlan_bridge_binding: Fix flaky operational state check", " - 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: Restore initial state on failed device_rename() in", " cfg802154_switch_netns()", " - ieee802154: Avoid calling WARN_ON() on -ENOMEM in", " cfg802154_switch_netns()", " - ieee802154: Remove WARN_ON() in cfg802154_pernet_exit()", " - ieee802154: fix kernel-infoleak in dgram_recvmsg()", " - mac802154: Prevent overwrite return code in", " mac802154_perform_association()", " - md/raid1: honor REQ_NOWAIT when waiting for behind writes", " - md/raid1: free r1_bio when REQ_NOWAIT is set and read would block on", " retry", " - netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()", " - netfilter: ipset: make sure gc is properly stopped", " - netfilter: nft_payload: reject offsets exceeding 65535 bytes", " - netfilter: nft_meta_bridge: add validate callback for get operations", " - netfilter: nft_flow_offload: zero device address for non-ether case", " - netfilter: nf_reject: skip iphdr options when looking for icmp header", " - netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak", " - mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()", " - irqchip/crossbar: Fix parent domain resource leak", " - alloc_tag: fix use-after-free in /proc/allocinfo after module unload", " - selftests/mm: restore default nr_hugepages value via exit trap in", " charge_reserved_hugetlb.sh", " - selftests/mm: restore default nr_hugepages value via exit trap in", " hugetlb_reparenting_test.sh", " - selftests/mm: fix hugetlb pathname construction in", " hugetlb_reparenting_test.sh", " - selftests/mm: fix cgroup task placement and drop memory.current checks", " in hugetlb_reparenting_test.sh", " - selftests/mm: size tmpfs according to PMD page size in", " split_huge_page_test", " - selftests/mm: free dynamically allocated PMD-sized buffers in", " split_huge_page_test", " - selftest/mm: register existing mapping with userfaultfd in hugetlb-", " mremap", " - selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap", " - selftests/mm: skip uffd-stress test when nr_pages_per_cpu is zero", " - 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", " - net: emac: Fix NULL pointer dereference in emac_probe", " - net/sched: act_ct: fix nf_connlabels leak on two error paths", " - net: airoha: Fix skb->priority underflow in airoha_dev_select_queue()", " - ipv6: ndisc: fix NULL deref in accept_untracked_na()", " - dpaa2-switch: do not accept VLAN uppers while bridged", " - 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", " - bpftool: Fix vmlinux BTF leak in cgroup commands", " - bpf: zero-initialize the fib lookup flow struct", " - bpf: Fix effective prog array index with BPF_F_PREORDER", " - power: sequencing: fix ABBA deadlock in pwrseq_device_unregister()", " - gpiolib: initialize return value in gpiochip_set_multiple()", " - 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()", " - ice: call netif_keep_dst() once when entering switchdev mode", " - rtc: isl1208: Balance enable_irq_wake() with disable_irq_wake() on", " cleanup", " - 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", " - i40e: Fix i40e_debug() to use struct i40e_hw argument", " - rtc: msc313: fix NULL deref in shared IRQ handler at probe", " - ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().", " - eth: bnxt: rename ring_err_stats -> ring_drv_stats", " - eth: bnxt: improve the timing of stats", " - ipv4: fib: Don't ignore error route in local/main tables.", " - md/raid5: use stripe state snapshot in break_stripe_batch_list()", " - md/raid5: avoid R5_Overlap races while breaking stripe batches", " - 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", " - gpio: davinci: fix IRQ domain leak on devm_kzalloc failure", " - 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: do not acquire dev->tx_global_lock in netdev_watchdog_up()", " - net: dsa: sja1105: round up PTP perout pin duration", " - veth: fix NAPI leak in XDP enable error path", " - net: usb: lan78xx: restore VLAN and hash filters after link up", " - 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", " - ipv6: fix state corruption during proxy_ndp sysctl restart", " - ipv6: fix missing notification for ignore_routes_with_linkdown", " - eth: fbnic: fix ordering of heartbeat vs ownership", " - thermal: testing: zone: Flush work items during cleanup", " - ACPI: processor_idle: Mark LPI enter functions as __cpuidle", " - 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: dsa: realtek: fix memory leak in rtl8366rb_setup_led()", " - net: phy: realtek: Clear MDIO_AN_10GBT_CTRL_ADV10G bit", " - octeontx2-af: Validate NIX maximum LFs correctly", " - 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", " - LoongArch: Move struct kimage forward declaration before use", " - LoongArch: BPF: Fix outdated tail call comments", " - LoongArch: BPF: Fix off-by-one error in tail call", " - ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count", " - net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync", " - dt-bindings: net: renesas,ether: Drop example \"ethernet-phy-", " ieee802.3-c22\" fallback", " - selftests: tls: size splice_short pipe by page size", " - 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", " - ALSA: FCP: Fix NULL pointer dereference in interface lookup", " - tracing: probes: fix typo in a log message", " - spi: sh-msiof: abort transfers when reset times out", " - ACPI: RIMT: Only defer the IOMMU configuration in init stage", " - riscv: Fix 32-bit call_on_irq_stack() frame pointer ABI", " - gpio: mvebu: fail probe if gpiochip registration fails", " - gpio: htc-egpio: use managed gpiochip registration", " - net: pse-pd: scope pse_control regulator handle to kref lifetime", " - seg6: validate SRH length before reading fixed fields", " - qede: fix out-of-bounds check for cqe->len_list[]", " - sctp: fix SCTP_RESET_STREAMS stream list length limit", " - MIPS: DEC: Ensure RTC platform device deregistration upon failure", " - MIPS: mm: Add check for highmem before removing memory block", " - ASoC: codecs: lpass-va-macro: Fix LPASS Codec Version for SC7280", " - hwmon: adm1275: Prevent reading uninitialized stack", " - hwmon: (pmbus) Fix passing events to regulator core", " - hwmon: (aspeed-g6-pwm-tach) Guard fan RPM calculation against divide-by-", " zero", " - ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump", " - usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()", " - net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy", " - net: libwx: fix VMDQ mask for 1-queue mode", " - 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", " - drm/panthor: Fix potential invalid pointer deref in", " group_process_tiler_oom()", " - drm/panthor: Don't overrule pending immediate ticks in", " sched_resume_tick()", " - drm/panthor: Fix a leak when a group is evicted before the tiler OOM is", " serviced", " - drm/panthor: Interrupt group start/resumption if group_bind_locked()", " fails", " - tracing/eprobes: Allow use of BTF names to dereference pointers", " - tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg", " - tracing/events: Fix to check the simple_tsk_fn creation", " - tracing: eprobe: read the complete FILTER_PTR_STRING pointer", " - tracing/fprobe: Fix NULL pointer dereference in fprobe_fgraph_entry()", " - tracing/probes: Make the $ prefix mandatory for comm access", " - irqchip/gic-v3-its: Fix OF node reference leak", " - irqchip/ts4800: Fix missing chained handler cleanup on remove", " - sctp: fix addr_wq_timer race in sctp_free_addr_wq()", " - virtio_net: disable cb when NAPI is busy-polled", " - cxgb4: Fix decode strings dump for T6 adapters", " - selftests: drv-net: tso: don't touch dangerous feature bits", " - 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: dualpi2: clear stale classification on filter miss", " - 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: Fix double netfs initialisation in afs_root_iget()", " - afs: use kvfree() to free memory allocated by kvcalloc()", " - afs: Remove erroneous seq |= 1 in volume lookup loop", " - afs: Fix bulk lookup malfunction due to change in dir_emit() API", " - afs: Fix misplaced inc of net->cells_outstanding", " - afs: Fix reinitialisation of the inode, in particular ->lock_work", " - afs: Fix callback service message parsers to pass through -EAGAIN", " - afs: Fix missing NULL pointer check in afs_break_some_callbacks()", " - afs: Fix vllist leak", " - afs: Fix lack of locking around modifications of net->cells_dyn_ino", " - afs: Fix premature cell exposure through /afs", " - 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", " - ovl: fix comment about locking order", " - iomap: guard io_size EOF trim against concurrent truncate underflow", " - netfs: Fix writethrough to use collection offload", " - netfs: Fix writeback error handling", " - netfs: Fix folio state after ENOMEM whilst under writeback iteration", " - drm/xe/pt: Fix NULL pointer dereference in xe_pt_zap_ptes_entry()", " - drm/xe/userptr: Hold notifier_lock for write on inject test path", " - drm/xe/hw_engine: Fix double-free of managed BO in error path", " - drm/xe/pf: Don't attempt to process FAST_REQ or EVENT relays", " - x86/uprobes: Keep shadow stack in sync for emulated CALLs", " - uprobes/x86: Use proper mm_struct in __in_uprobe_trampoline", " - cifs: Fix missing credit release on failure in cifs_issue_read()", " - ata: sata_gemini: unwind clocks on IDE pinctrl errors", " - ata: libata-scsi: limit simulated SCSI command copy to response length", " - 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: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()", " - HID: bpf: Fix hid_bpf_get_data() range check", " - selftests/hid: Load only requested struct_ops maps", " - selftests/hid: Cover hid_bpf_get_data() size overflow", " - arm64/sysreg: Fix BWE field encoding in ID_AA64DFR2_EL1", " - net: usb: net1080: validate packet_len before pad-byte access in", " rx_fixup", " - netfilter: xt_u32: reject invalid shift counts", " - netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()", " - netfilter: nft_set_rbtree: get command skips end element with open", " interval", " - netfilter: xt_connmark: reject invalid shift parameters", " - net/mlx5: LAG, MPESW, Fix missing complete() on devcom error", " - net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation", " - net/mlx5e: Fix HV VHCA stats agent registration race", " - net/mlx5e: Fix publication race for priv->channel_stats[]", " - net: microchip: vcap: fix races on the shared Super VCAP block", " - net: qualcomm: rmnet: validate MAP frame length before ingress parsing", " - net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload", " - 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: sco: Fix a race condition in sco_sock_timeout()", " - Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length", " - Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()", " - Bluetooth: L2CAP: fix tx ident leak for commands without a response", " - ring-buffer: Fix event length with forced 8-byte alignment", " - accel/amdxdna: Use unsigned long for nr_pages in amdxdna_hmm_register()", " - net/tls: Consume empty data records in tls_sw_read_sock()", " - net: usb: lan78xx: disable VLAN filter in promiscuous mode", " - gpio: dwapb: reduce allocation to single kzalloc", " - gpio: dwapb: Defer clock gating until noirq", " - tracing: Make tracepoint_printk static as not exported", " - accel/amdxdna: Fix potential amdxdna_umap lifetime race", " - drm/v3d: Reject invalid indirect BO handle in indirect CSD setup", " - net: mdio: select REGMAP_MMIO instead of depending on it", " - net/sched: cake: reject overhead values that underflow length", " - octeontx2-pf: check DMAC extraction support before filtering", " - perf/x86/amd/core: Avoid enabling BRS from the SVM reload path", " - gpio: mvebu: free generic chips on unbind", " - ipv4: igmp: annotate data-races around im->users", " - ipv4: igmp: annotate data-races around timer-related fields", " - ipv4: igmp: Fix potential memory leaks in igmp_mod_timer() and", " igmp_stop_timer()", " - ipvs: pass parsed transport offset to state handlers", " - ipvs: use parsed transport offset in TCP state lookup", " - s390/zcrypt: Remove the empty file", " - SUNRPC: release lower rpc_clnt if killed waiting for XPRT_LOCKED", " - 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", " - drm/xe: remove duplicate include", " - smb: client: fix overflow in passthrough ioctl bounds check", " - idpf: add padding to PTP virtchnl structures", " - 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", " - octeontx2-pf: clear stale mailbox IRQ state before request_irq()", " - octeontx2-vf: clear stale mailbox IRQ state before request_irq()", " - arm64: fpsimd: Fix type mismatch in sve_{save,load}_state()", " - arm64: dts: s32g3: Fix SWT8 watchdog address", " - ARM: dts: imx6ul-var-som: fix warning for non-existent dc-supply", " property", " - arm64: dts: qcom: sdm630: describe adsp_mem region properly", " - arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Ringneck", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix ADC sampling times", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move divergent mecio1 ADC", " channels to board files", " - arm64: dts: ti: k3-am62a7-sk: Add bootph-all tag to vqmmc", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Enable internal ADC reference", " - arm64: dts: imx8ulp-evk: Correct Type-C int GPIO flags", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix GPIO names typo", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move gpio-line-names to board", " files", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix expander gpio line typo", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move expander gpio-line-names to", " board files", " - LoongArch: KVM: Validate irqchip index in irqfd routing", " - 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()", " - powerpc/pseries/Kconfig: Enable CONFIG_VPA_PMU to be used with KVM", " - KVM: s390: pci: Fix GISC refcount leak on AIF enable failure", " - KVM: s390: pci: Fix handling of AIF enable without AISB", " - KVM: SEV: Do not allow intra-host migration/mirroring of SNP VMs", " - KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs", " - KVM: x86: Nullify irqfd->producer if updating IRTE for bypass fails", " - KVM: nVMX: Put vmcs12 pages if nested VM-Enter fails due to invalid", " guest state", " - KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers", " - KVM: arm64: nv: Drop bogus WARN for write to ZCR_EL2", " - KVM: arm64: nv: Write ESR_EL2 for injected nested SError exceptions", " - KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()", " - 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: efifb: fix memory leak in efifb_probe()", " - 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: Check runtime resume during probe", " - ASoC: mediatek: mt8192: Release reserved memory on cleanup", " - ASoC: mediatek: mt8183: Check runtime resume during probe", " - 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: nft_set_pipapo: don't leak bad clone into future transaction", " - 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", " - selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()", " - selinux: fix incorrect execmem checks on overlayfs", " - 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/brs: Fix kernel address leakage", " - perf/x86/amd/lbr: Fix kernel address leakage", " - cpufreq: schedutil: Fix uncleared need_freq_update on the .adjust_perf()", " path", " - cpufreq: intel_pstate: Set non-turbo capacity to HWP_GUARANTEED_PERF()", " - 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: retrieve ethhdr after potential skb realloc on RX", " - 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: ensure minimal ethernet header on TX", " - 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: clean untagged VLAN on netdev registration failure", " - batman-adv: frag: fix primary_if leak on failed linearization", " - batman-adv: mcast: avoid OOB read of num_dests header", " - 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", " - lockd: Plug nlm_file leak when nlm_do_fopen() fails", " - lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure", " - 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()", " - mm/mm_init: fix pageblock migratetype for ZONE_DEVICE compound pages", " - power: supply: cpcap-battery: Fix missing nvmem_device_put() causing", " reference leak", " - power: supply: max17042: fix OF node reference imbalance", " - mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch", " - mm/memory_hotplug: fix incorrect altmap passing in error path", " - 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: bound NTFS_DE view.data_off in", " UpdateRecordData{Root,Allocation}", " - ntfs3: cap RESTART_TABLE free-chain walker at rt->used", " - ntfs3: fix out-of-bounds read in decompress_lznt", " - landlock: Fix LANDLOCK_SCOPE_SIGNAL bypass on the SIGIO path", " - power: supply: charger-manager: fix refcount leak in is_full_charged()", " - selftests/landlock: Test SCOPE_SIGNAL on the SIGIO/fowner pgid path", " - 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", " - 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()", " - proc: only bump parent nlink when registering directories", " - fs/proc: fix KPF_KSM reported for all anonymous pages", " - powerpc/dt_cpu_ftrs: Set CPU_FTR_P11_PVR for Power11 and later", " processors", " - mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE", " - kcov: use WRITE_ONCE() for selftest mode stores", " - mtd: slram: remove failed entries from the device list", " - 9p: skip nlink update in cacheless mode to fix WARN_ON", " - power: supply: bq257xx: Fix VSYSMIN clamping logic", " - scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()", " - scsi: sas: Skip opt_sectors when DMA reports no real optimization hint", " - openrisc: Add full instruction cache invalidate functions", " - 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: fix UBSAN array-index-out-of-bounds in ocfs2_sum_rightmost_rec", " - 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: host: pci_generic: Fix the physical function check", " - 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()", " - s390/pkey: Check length in PKEY_VERIFYPROTK ioctl", " - s390/pkey: Check length in pkey_pckmo handler implementation", " - mtd: spi-nor: swp: Improve locking user experience", " - mtd: spi-nor: spansion: use die erase for multi-die devices only", " - mtd: rawnand: Pause continuous reads at block boundaries", " - openrisc: Fix jump_label smp syncing", " - mtd: maps: vmu-flash: fix NULL pointer dereference in initialization", " - taskstats: retain dead thread stats in TGID queries", " - irqchip/crossbar: Use correct index in crossbar_domain_free()", " - tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()", " - tpm: tpm2-sessions: wait for async KPP completion in tpm_buf_append_salt", " - sunrpc: fix uninitialized xprt_create_args structure", " - dmaengine: tegra: Fix burst size calculation", " - dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and", " ABORT_INT_MASK", " - platform/x86: dell-laptop: fix missing cleanups in init error path", " - platform/x86: ISST: Restore SST-PP control to all domains", " - 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", " - platform/x86/amd/pmc: Don't log during intermediate wakeups", " - pkey: Move keytype check from pkey api to handler", " - 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", " - hwmon: (max6697) add missing 'select REGMAP_I2C' to Kconfig", " - i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)", " - i2c: imx: fix locked bus on SMBus block-read of 0 (IRQ)", " - i2c: mediatek: fix WRRD for SoCs without auto_restart option", " - i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()", " - i2c: spacemit: fix spurious IRQ handling returning IRQ_HANDLED", " - ice: fix ice_init_link() error return preventing probe", " - tcp: Decrement tcp_md5_needed static branch", " - ufs: core: tracing: Do not dereference pointers in TP_printk()", " - xen/gntdev: fix error handling in ioctl", " - xfrm: use compat translator only for u64 alignment mismatch", " - 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()", " - NFS: Charge unstable writes by request size, not folio size", " - nvme-apple: Prevent shared tags across queues on Apple A11", " - nvmet: fix refcount leak in nvmet_sq_create()", " - netdev-genl: report NAPI thread PID in the caller's pid namespace", " - can: esd_usb: kill anchored URBs before freeing netdevs", " - can: isotp: use unconditional synchronize_rcu() in isotp_release()", " - can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER", " - can: isotp: serialize TX state transitions under so->rx_lock", " - 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: Reset register bounds before narrowing retval range in", " check_mem_access()", " - bpf,fork: wipe ->bpf_storage before bailouts that access it", " - bpf: Add missing access_ok call to copy_user_syms", " - block: remove redundant GD_NEED_PART_SCAN in add_disk_final()", " - block: fix race in blk_time_get_ns() returning 0", " - block: fix IORING_URING_CMD_REISSUE flags check in blkdev_uring_cmd", " - 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-pcache: reject option groups without values", " - 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: fix leaking uninitialized kernel memory", " - dm-integrity: fix a bug if the bio is out of limits", " - dm-integrity: don't increment hash_offset twice", " - dm-verity: avoid double increment of &use_bh_wq_enabled", " - dm-verity: fix a possible NULL pointer dereference", " - dm-verity: increase sprintf buffer size", " - dm-verity: make error counter atomic", " - dma-fence: Make dma_fence_dedup_array() robust against 0-count input", " - accel/amdxdna: Fix use-after-free in amdxdna_gem_dmabuf_mmap()", " - accel/ivpu: Reject firmware log with size smaller than header", " - 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: 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 - only expose sysfs attributes on control interface", " - 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 firmware leak in async update", " - 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", " - tracing/user_events: Fix use-after-free in user_event_mm_dup()", " - wifi: libertas_tf: fix use-after-free in lbtf_free_adapter()", " - posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu()", " - selftests/ftrace: Drop invalid top-level local in test_ownership", " - cpu: hotplug: Preserve per instance callback errors", " - cpu: hotplug: Bound hotplug states sysfs output", " - gpio: mt7621: more robust management of IRQ domain teardown", " - gpio: tegra: do not call pinctrl for GPIO direction", " - gpio: mt7621: be sure IRQ domain is created before exposing GPIO chips", " - gpio-f7188x: Add support for NCT6126D version B", " - gpio: mt7621: avoid corruption of shared interrupt trigger state", " - gpios: palmas: add .get_direction() op", " - net: sit: require CAP_NET_ADMIN in the device netns for changelink", " - net: ethernet: ti: icssg: guard PA stat lookups", " - 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", " - selftests: net: fix file owner for broadcast_ether_dst test", " - 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", " - net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for", " changelink", " - octeontx2-af: Free BPID bitmap on setup failure", " - 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", " - platform/x86/amd/pmc: Avoid logging \"(null)\" for DMI values", " - net/sched: sch_teql: move rcu_read_lock()/spin_lock() from _bh variants", " - drm/xe/userptr: Stub notifier_lock helpers when DRM_GPUSVM=n", " - pwm: rzg2l-gpt: Fix period_ticks type from u32 to u64", " - LoongArch: Fix nr passing in set_direct_map_valid_noflush()", " - LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()", " - ipmi: Fix user refcount underflow in event delivery", " - ipmi: fix refcount leak in i_ipmi_request()", " - bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()", " - rtc: renesas-rtca3: Fix PIE clear polling condition in alarm setup error", " path", " - 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", " - fhandle: reject detached mounts in capable_wrt_mount()", " - hwmon: (max1619) add missing 'select REGMAP' to Kconfig", " - tracing/probes: Fix double addition of offset for @+FOFFSET", " - net/mlx5: HWS, fix matcher leak on resize target setup failure", " - 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", " - mm/compaction: handle free_pages_prepare() properly in compaction_free()", " - irqchip/irq-riscv-imsic-early: Fix fwnode leak on state setup failure", " - s390/monwriter: Reject buffer reuse with different data length", " - mac802154: remove interfaces with RCU list deletion", " - octeontx2-pf: fix SQB pointer leak on init failure", " - selftests: net: make busywait timeout clock portable", " - llc: fix SAP refcount leak in llc_ui_autobind()", " - ipvs: use parsed transport offset in SCTP state lookup", " - macsec: don't read an unset MAC header in macsec_encrypt()", " - dibs: loopback: validate offset and size in move_data()", " - net: macb: drop in-flight Tx SKBs on close", " - arm64: smp: Fix hot-unplug tearing by forcing unregistration", " - cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()", " - fs/resctrl: Free mon_data structures on rdt_get_tree() failure", " - fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list", " - ata: libata-core: Skip HPA resize for locked drives", " - ata: libata-core: Allow capacity transition to zero for locked drives", " - riscv: Prevent NULL pointer dereference in machine_kexec_prepare()", " - tracing/osnoise: Call synchronize_rcu() when unregistering", " - s390/diag: Add missing array_index_nospec() call to", " memtop_get_page_count()", " - s390/mm: Fix type mismatch in get_align_mask().", " - selftests/rseq: Fix a building error for riscv arch", " - 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", " - selftests/landlock: Skip scoped_signal subtest with MSG_OOB if not", " available", " - selftests/landlock: Fix screwed up pointers in the scoped_signal_test", " - mmc: sdhci-esdhc-imx: restore pinctrl before restoring ios timing on", " resume", " - powerpc/pseries: fix memory leak on krealloc failure in papr_init", " - net/mlx5: free mlx5_st_idx_data on final dealloc", " - wifi: rt2x00: avoid full teardown before work setup in probe", " - wifi: mwifiex: fix roaming to different channel in host_mlme mode", " - wifi: mac80211: fix memory leak in ieee80211_register_hw()", " - wifi: brcmfmac: cyw: fix heap overflow on a short auth frame", " - riscv: vdso: Do not use LTO for the vDSO", " - 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", " - reset: sunxi: fix memory region leak on ioremap failure", " - powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()", " - wifi: cfg80211: validate EHT MLE before MLD ID read", " - wifi: ieee80211: validate MLE common info length", " - 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", " - mmc: block: fix RPMB device unregister ordering", " - mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe()", " method", " - mmc: sdhci-esdhc-imx: remove unnecessary mmc_card_wake_sdio_irq check", " for tuning save/restore", " - mmc: sdhci-esdhc-imx: restore DLL override for DDR modes on resume", " - mmc: sdhci-esdhc-imx: fix esdhc_change_pinstate() to allow default state", " restore", " - mmc: sdhci-esdhc-imx: disable irq during suspend to fix unhandled", " interrupt", " - mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspend", " - mmc: sdhci-esdhc-imx: make non-fatal errors non-blocking in suspend", " - mmc: sdhci-esdhc-imx: fix resume error handling", " - crypto: xilinx-trng - Remove crypto_rng interface", " - 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: hid-sensor-rotation: Fix stale or zero output when reading raw", " values", " - ALSA: scarlett2: Allow selecting config_set by firmware version", " - ALSA: scarlett2: Update offsets for 2i2 Gen 4 firmware 2417", " - firmware_loader: Add cancel helper for async requests", " - ALSA: hda/tas2781: Cancel async firmware request at unbind", " - binder: Use LIST_HEAD() to initialize on stack list head", " - binder: cache secctx size before release zeroes it", " - staging: rtl8723bs: fix spaces around binary operators", " - Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister", " - Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()", " - proc: rename proc_setattr to proc_nochmod_setattr", " - usb: dwc3: Support USB3340x ULPI PHY high-speed negotiation.", " - usb: dwc3: fix dwc3_readl() and dwc3_writel() calls in dwc3_ulpi_setup()", " - usb: atm: ueagle-atm: use dev_dbg() for 'device found' message", " - usb: atm: ueagle-atm: remove function entry/exit debug messages", " - usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()", " - btrfs: remove folio parameter from ordered io related functions", " - KVM: arm64: Ensure level is always initialized when relaxing perms", " - KVM: arm64: Fix propagation of TLBI level in", " kvm_pgtable_stage2_relax_perms()", " - mm/damon/core: always put unsuccessfully committed target pids", " - mm/damon/core: trace esz at first setup", " - samples/damon/mtier: fail early if address range parameters are invalid", " - perf callchain: Handle multiple address spaces", " - soc: fsl: qe_ports_ic: Add missing cleanup on device removal", " - drm/rockchip: inno-hdmi: Switch to drmm_kzalloc()", " - accel/amdxdna: Create shared functions for AIE2 and AIE4", " - Revert \"UBUNTU: SAUCE: accel/amdxdna: Support sensors for column", " utilization\"", " - accel/amdxdna: Support sensors for column utilization", " - accel/amdxdna: Adjust size for copy_to_user()", " - accel/amdxdna: Handle DETACH_DEBUG_BO through config_debug_bo path", " - accel/amdxdna: Fix order of canceled mailbox messages", " - accel/amdxdna: Guard management mailbox channel cleanup against NULL", " pointer", " - drm/amdkfd: fix redundant MQD iterations in GFX v12.1", " - wifi: ath12k: Fix invalid IRQ requests during AHB probe", " - libbpf: Fix deduplication of typedef with base definitions", " - spi: atcspi200: Use helper function devm_clk_get_enabled()", " - spi: atcspi200: fix use-after-free when driver unbind", " - arm64: dts: rockchip: Fix vdec register blocks order on RK3576", " - arm64: dts: rockchip: Update vdec register blocks order on RK3588", " - dt-bindings: net: bluetooth: qualcomm: Fix WCN6855 regulator names", " - x86/bug: Add printf() validation to HAVE_ARCH_BUG_FORMAT_ARGS WARNs", " - arm64: dts: qcom: milos: Reduce rmtfs_mem size to 2.5MiB", " - arm64: dts: qcom: sdm845-oneplus: Drop address from framebuffer node", " - arm64: dts: qcom: sdm845-shift-axolotl: Correct touchscreen sleep state", " - soc: xilinx: Fix race condition in event registration", " - wifi: ath11k: cancel SSR work items during PCI shutdown", " - ixgbe: fix unaligned u32 access in ixgbe_update_flash_X550()", " - objtool/klp: Fix is_uncorrelated_static_local() for Clang", " - objtool/klp: Fix .data..once static local non-correlation", " - objtool/klp: Fix create_fake_symbols() skipping entsize-based sections", " - objtool/klp: Fix handling of zero-length .altinstr_replacement sections", " - objtool/klp: Fix cloning of zero-length section symbols", " - objtool/klp: Fix extraction of text annotations for alternatives", " - objtool/klp: Fix relocation conversion failures for R_X86_64_NONE", " - objtool/klp: Use sym->demangled_name for symbol_name hash", " - objtool/klp: Match symbols based on demangled_name for global variables", " - objtool: Replace iterator callback with for_each_sym_by_mangled_name()", " - objtool: Fix reloc hash collision in find_reloc_by_dest_range()", " - klp-build: Fix hang on out-of-date .config", " - klp-build: Fix checksum comparison for changed offsets", " - riscv: dts: microchip: gpio controllers on mpfs need 2 interrupt cells", " - riscv: dts: microchip: remove gpio hogs from beaglev-fire", " - wifi: cfg80211: restrict LMR feedback check to TB and non-TB ranging", " - drm/panel: Clean up SOFEF00 config dependencies", " - drm/panel: Clean up S6E3FC2X01 config dependencies", " - arm64: dts: marvell: samsung-coreprimevelte: Increase touchscreen", " voltage", " - arm64: dts: imx8mn-vhip4-evalboard-v1: Correct interrupt flags", " - arm64: dts: imx8mn-vhip4-evalboard-v2: Correct interrupt flags", " - crypto: ccp - Check for page allocation failure correctly in TIO", " - crypto: ccp - Initialize data during __sev_snp_init_locked()", " - accel/amdxdna: Fix clflush buffer size", " - ntb: Store original DMA address for future release", " - ntb: Use consistent DMA attributes when freeing DMA mappings", " - riscv: dts: spacemit: k3: add clock tree", " - dts: riscv: spacemit: correct 32k clock frequency", " - arm64: dts: qcom: sdm660: set cdsp compute-cbs' regs properly", " - arm64: dts: qcom: sdm630: set adsp compute-cbs' regs properly", " - arm64: dts: qcom: lemans: Move PCIe devices into soc node", " - sockptr: fix usize check in copy_struct_from_sockptr() for user pointers", " - arm64: dts: mediatek: mt7988a-bpi-r4pro: rework pcie gpio-hog handling", " - rhashtable: give each instance its own lockdep class", " - thermal: hwmon: Register a hwmon device for each thermal zone", " - crypto: ccp/sev-dev-tsm - bail out early when pdev->bus is NULL", " - crypto: safexcel - Fix potential memory leak in safexcel_pci_probe()", " - net/sched: add qdisc_qlen_inc() and qdisc_qlen_dec()", " - net/sched: sch_dualpi2: annotate data-races in dualpi2_dump_stats()", " - tools/rtla: Fix --dump-tasks usage in timerlat", " - rtla: Stop the record trace on interrupt", " - dm: limit target bio polling to one shot", " - selftests/bpf: Override EXTRA_LDFLAGS for static builds", " - sched/fair: Update util_est after updating util_avg during dequeue", " - hfs: fix incorrect inode ID assignment in hfs_new_inode()", " - vfio: selftests: Fix out-of-tree build with make O=", " - vfio: selftests: Allow builds when ARCH=x86", " - vfio/xe: avoid duplicate reset in xe_vfio_pci_reset_done", " - arm64: dts: qcom: kaanapali: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sdm845-xiaomi-beryllium: Correct IPA FW path", " - ASoC: mediatek: mt8189: Fix probe resource cleanup", " - drm/msm/mdss: correct UBWC programming sequences", " - tools/nolibc: stackprotector: Avoid stalling program startup if crng is", " not init yet", " - ASoC: dapm: Fix widget lookup with prefixed names across DAPM contexts", " - ACPI: PAD: Fix teardown ordering in acpi_pad_remove()", " - wifi: ath12k: fix error unwind on arch_init() failure in PCI probe", " - cpufreq: governor: Fix data races on per-CPU idle/nice baselines", " - cpufreq: governor: Fix stale prev_cpu_nice spike when enabling", " ignore_nice_load", " - dt-bindings: vendor-prefixes: Add Verbatim Corporation", " - drm/tegra: fbdev: Do not assign to struct drm_fb_helper.info", " - rust: devres: add 'static bound to Devres", " - lib/base64: validate before writing in decode tail path", " - rust: uaccess: use INLINE_COPY_TO_USER to guard copy_to_user()", " - uaccess: unify inline vs outline copy_{from,to}_user() selection", " - uaccess: minimize INLINE_COPY_USER-related ifdefery", " - crypto: ccp/tsm - Enable the root port after the endpoint", " - firmware: samsung: acpm: Add devm_acpm_get_by_phandle helper", " - firmware: samsung: acpm: remove compile-testing stubs", " - drm/msm/a8xx: Make a8xx_recover IFPC safe", " - drm/msm/a8xx: Fix RSCC offset", " - EDAC/igen6: Fix memory topology parsing for Panther Lake-H SoCs", " - arm: dts: bcm2711: Fix typo in gpio-line-names", " - arm64: dts: renesas: r8a78000: Fix GIC-720AE View 1 Redistributor", " description", " - arm64: dts: renesas: ironhide: Describe all reserved memory", " - md: replace wait loop with wait_event() in md_handle_request()", " - md/raid1,raid10: fix deadlock in read error recovery path", " - md/raid1,raid10: fix error-path detection with md_cloned_bio()", " - md/raid1,raid10: fix bio accounting for split md cloned bios", " - liveupdate: Use refcount_t for FLB reference counts", " - liveupdate: Reference count incoming FLB data", " - liveupdate: skip serialization for context-preserving kexec", " - liveupdate: fix TOCTOU race in luo_session_retrieve()", " - liveupdate: block session mutations during reboot", " - spi: imx: replace dmaengine_terminate_all() with", " dmaengine_terminate_sync()", " - wifi: ath12k: fix memory leak in ath12k_wifi7_dp_rx_h_verify_tkip_mic()", " - wifi: ath12k: fix inconsistent arvif state in vdev_create error paths", " - ACPI: button: Fix lid_device value leak past driver removal", " - drm/amd/pm: Add empty string validation to sysfs store functions", " - accel/amdxdna: Return errors for failed debug BO commands", " - mm: preserve PG_dropbehind flag during folio split", " - perf/x86/intel/uncore: Fix PCI device refcount leak in UPI discovery", " - wifi: wlcore: enable the right set of ciphers", " - cxl/test: Fix __fortify_panic", " - bpf: Take mmap_lock in zap_pages()", " - ocfs2: fix out-of-bounds write in ocfs2_remove_refcount_extent", " - cxl/pci: Fix the incorrect check of pci_read_config_word() return", " - cxl/pci: Convert PCIBIOS errors to errno on DVSEC config accesses", " - netfilter: cttimeout: detach dataplane timeout policy and repurpose", " refcount", " - arm64: dts: imx94: fix DDR PMU interrupt number", " - arm64: dts: freescale: fsl-ls1028a-tqmls1028a-mbls1028a: switch mmc", " aliases", " - selftests/bpf: Fix flaky file_reader test", " - riscv: alternative: Use IS_ENABLED() over ifdeffery for", " apply_vdso_alternatives()", " - riscv: alternative: Pass vDSO start as parameter to", " apply_vdso_alternatives()", " - riscv: alternative: Also patch the CFI vDSO", " - bpf: Verifier support for sleepable tracepoint programs", " - bpf: Reject sleepable BPF_LSM_CGROUP programs at load time", " - netfilter: flowtable: avoid num_encaps underflow on bridge VLAN untag", " - filelock: fix break_lease() stub signature for CONFIG_FILE_LOCKING=n", " - wifi: mac80211: bound S1G TIM PVB walk to the TIM element", " - ACPI: processor: Add cpuidle driver check in", " acpi_processor_register_idle_driver()", " - RDMA/nldev: Fix locking when accessing mr->pd", " - scsi: ufs: core: Handle PM commands timeout before SCSI EH", " - iommufd: Destroy the pages content after detaching from dmabuf", " - lib/test_hmm: fix memory leak in dmirror_migrate_to_system()", " - rust: kbuild: show the right `quiet_cmd_rustc_procmacrolibrary`", " - remoteproc: qcom_q6v5_wcss: drop redundant wcss_q6_bcr_reset", " - wifi: mt76: mt7996: remove redundant pdev->bus check in probe", " - wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bits", " - memory: tegra186-emc: stop borrowing MC aggregate hook for EMC", " - PM: QoS: Fix misc device registration unwind", " - btrfs: lzo: reject compressed segment that overflows the compressed", " input", " - ixgbe: do not configure xps for XDP queues", " - bpf: Cancel special fields on map value recycle", " - clocksource: move NXP timer selection to drivers/clocksource", " - [Config] Allow certain NXP timer selections for arm64", " - vduse: fix compat handling for VDUSE_IOTLB_GET_FD/VDUSE_VQ_GET_INFO", " - iomap: pass the correct len to fserror_report_io in __iomap_write_begin", " - ASoC: cs35l56: Prevent double-free of debugfs", " - ASoC: cs35l56: Cleanup if component_probe fails", " - hwmon: (gpd-fan): drop global driver data and use per-device allocation", " - hwmon: (gpd-fan): Initialize EC before registering hwmon device", " - hwmon: (gpd-fan): fix race condition between device removal and sysfs", " access", " - ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT", " - cxl/test: Verify cmd->size_in before accessing payload", " - m68k: mcf5441x: fix clocks numbering", " - pinctrl: airoha: an7583: add missed gpio32 pin group", " - pinctrl: airoha: an7583: fix misprint in gpio19 pinconf", " - pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin", " function", " - pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin", " function", " - pinctrl: airoha: fix pwm pin function for an7581 and an7583", " - pinctrl: airoha: an7583: fix gpio21 pin group", " - pinctrl: airoha: an7583: add missed gpio22 pin group", " - pinctrl: airoha: an7583: fix phy1_led1 pin function", " - pinctrl: airoha: an7583: remove undefined groups from pcm_spi pin", " function", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_setup() for non-", " serdev device", " - Bluetooth: btintel: Replace CNVi id with hardware variant", " - Bluetooth: btintel: Add DSBR support for ScP2 onwards", " - Bluetooth: btintel_pcie: Load IOSF debug regs by controller variant", " - ASoC: cs35l56: Fix wrong error test on simple_write_to_buffer()", " - ASoC: SOF: Intel: select SND_SOC_SDW_UTILS=y from", " SND_SOC_SOF_HDA_GENERIC=y", " - ASoC: meson: aiu: Validate written enum values", " - ASoC: topology: Check PCM and DAI name strings before use", " - ipv4: fib: Don't dump dying fib_info in fib_leaf_notify().", " - iommu/dma-iommu: Fix wrong scatterlist length assignment in P2PDMA path", " - iommufd: Clarify IOAS_MAP_FILE dma-buf support", " - cxl/region: Fill first free targets[] slot during auto-discovery", " - vfio: selftests: Ensure libvfio output dirs are always created", " - cxl/region: Block region delete during region creation", " - cxl/region: Resolve region deletion races", " - cxl/memdev: Pin parents for entire memdev lifetime", " - net: airoha: Fix error handling in airoha_ppe_flush_sram_entries()", " - netfilter: nft_fwd_netdev: use recursion counter in neigh egress path", " - netfilter: nf_dup_netdev: add nf_dev_xmit_recursion*() helpers and use", " them", " - geneve: Fix off-by-one comparing with GRO_LEGACY_MAX_SIZE", " - smb: client: fix conflicting option validation for new mount API", " - btrfs: Drop WQ_PERCPU from ordered_flags in btrfs_init_workqueues()", " - bpf: Guard __get_user acesss with access_ok for uprobe_multi data", " - net: ti: icssg-prueth: Fix AF_XDP fill ring alloc and wakeup condition", " - net: ti: icssg: Use undirected TX tag for native XDP in HSR offload mode", " - net: ti: icssg: Use undirected TX tag for XDP zero copy in HSR offload", " mode", " - RDMA/bnxt_re: Free CQ toggle page after firmware teardown", " - RDMA/bnxt_re: Reject GET_TOGGLE_MEM when toggle page was not allocated", " - RDMA/hns: Fix memory leak of bonding resources", " - mfd: bd72720: Drop BUCK11 ID", " - 9p: Add missing read barrier in virtio zero-copy path", " - perf dwarf-aux: Fix libdw segmentation fault in cu_walk_functions_at", " - perf dwarf-aux: Fix libdw API contract violations", " - perf srcline: Introduce inline_node__clear_frames()", " - perf libdw: Fix libdw API contract violations and memory leaks", " - perf probe-finder: Fix libdw API contract violations", " - perf annotate-data: Fix libdw API contract violations", " - coresight: tmc: Fix overflow when calculating is bigger than 2GiB", " - perf tool: Fix missing schedstat delegates and dont_split_sample_group", " in delegate_tool", " - PCI: intel-gw: Move interrupt enable to own function", " - PCI: intel-gw: Enable clock before PHY init", " - PCI: intel-gw: Add .start_link() callback", " - bus: mhi: ep: Add missing state_lock protection for mhi_state access", " - PCI: dwc: Apply ECRC workaround for DesignWare cores prior to 5.10a", " - PCI: qcom: Set max OPP before DBI access during resume", " - perf pmu-events AMD: Switch l2_itlb_misses to", " bp_l1_tlb_miss_l2_tlb_miss.all", " - perf unwind: Refactor get_entries to allow dynamic libdw/libunwind", " selection", " - coresight: Handle helper enable failure properly", " - mailbox: don't free the channel if the startup callback failed", " - PCI/pwrctrl: Lock device when calling device_is_bound()", " - coresight: platform: defer connection counter increment until alloc", " succeeds", " - platform/x86: classmate-laptop: Address memory leaks on driver removal", " - clk: microchip: mpfs-ccc: fix peripheral driver registration failures", " after oob fix", " - perf sample: Add evsel to struct perf_sample", " - perf event: Fix size of synthesized sample with branch stacks", " - perf inject: Fix itrace branch stack synthesis", " - gpib: cb7210: Fix region leak when request_irq fails", " - timers/migration: Update stale @online doc to @available", " - clk: spacemit: k3: Switch to pll2_d6 as parent for PCIe clock", " - clk: spacemit: k3: Fix PCIe clock register offset", " - fs/ntfs3: fix wrong LCN in run_remove_range() when splitting a run", " - ntfs3: Allocate iomap inline_data using alloc_page", " - perf sample: Add file_offset field to struct perf_sample", " - perf sched: Replace BUG_ON on invalid CPU with graceful skip", " - perf sched: Fix NULL dereference in latency_runtime_event", " - perf sched: Fix comp_cpus heap overflow with cross-machine recordings", " - perf tools: Guard remaining test_bit calls from OOB sample CPU", " - perf sched: Fix thread reference leaks in timehist_get_thread()", " - perf sched: Use is_idle_sample() for idle thread runtime cast guard", " - perf sched: Fix thread reference leak in idle hist processing", " - perf sched: Free callchain nodes in idle thread cleanup", " - docs: memfd_preservation: fix rendering of ABI documentation", " - virtio: add missing kernel-doc for map and vmap members", " - fs/ntfs3: prevent potential lcn remains uninitialized", " - perf tools: NULL bitmap pointers after bitmap_free()", " - perf tools: Use scnprintf() in build_id__snprintf() and hwmon", " read_events()", " - perf data convert json: Fix addr_location leak on time-filtered samples", " - perf tools: Use mkostemp() for O_CLOEXEC on temporary files", " - phy: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put", " in reset", " - sparc: Avoid -Wunused-but-set-parameter in clear_user_page()", " - apparmor: release exe file resources on path failure", " - apparmor: remove unnecessary goto and associated label", " - apparmor: Fix inverted comparison in cache_hold_inc()", " - i3c: mipi-i3c-hci: Fix suspend behavior when bus disable falls back to", " software reset", " - i3c: master: Serialize i3c_set_hotjoin() with the maintenance lock", " - i3c: mipi-i3c-hci: Fix race in i3c_hci_addr_to_dev()", " - perf maps: Add maps__mutate_mapping", " - perf c2c: Free format list entries when releasing c2c hist entries", " - regcache: Do not overwrite error code when finalizing cache after error", " - erofs: call erofs_exit_ishare() before rcu_barrier()", " - perf c2c: Free format list entries when c2c_hists__init() fails", " - perf c2c: Fix hist entry and format list leaks in c2c_he_free()", " - drm/amd/display: Skip PHY SSC reduction on some 8K panels", " - net: ethernet: mtk_eth_soc: fix supported_interface set after", " phylink_create", " - selftests/ftrace: Fix trace_marker_raw test on 64K page kernels", " - octeontx2-af: npc: Log successful MCAM drop-on-non-hit install at debug", " level", " - netconsole: don't drop the last byte of a full-sized message", " - eth: fbnic: take netif_addr_lock_bh() around rx mode address programming", " - arm64: static_call: include asm/insns.h", " - md/raid1: fix writes_pending and barrier reference leaks on write", " failures", " - md/raid10: fix writes_pending leak on write request failures", " - md/raid10: fix writes_pending and barrier reference leaks on discard", " failures", " - netfilter: ipset: Don't use test_bit() in lockless RCU readers in bitmap", " types", " - selftests/mm: fix hugetlb pathname construction in", " charge_reserved_hugetlb.sh", " - selftests/mm: run_vmtests.sh: free memory if available memory is low", " - selftests/mm: move hwpoison setup into run_test() and silence modprobe", " output for memory-failure category", " - selftests/mm: remove hardcoded THP sizing assumptions in hmm tests", " - net: dst_metadata: fix false-positive memcpy overflow in tun_dst_unclone", " - bpf: Fix partial copy of non-linear test_run output", " - bpf: Fix BPF_PROG_ASSOC_STRUCT_OPS last field check", " - erofs: handle 48-bit blocks_hi for compressed inodes", " - ASoC: cs530x: Fix expected MCLK rates for CS5302/4/8", " - PCI: endpoint: pci-epf-vntb: Document legacy MSI doorbell offset", " - PCI: endpoint: pci-epf-vntb: Defer pci_epc_raise_irq() out of atomic", " context", " - PCI: endpoint: pci-epf-vntb: Report 0-based doorbell vector via", " ntb_db_event()", " - e1000e: Reconfigure PLL clock gate timeout and re-enable K1 on Meteor", " Lake", " - bpf: Guard conntrack opts error writes", " - selftests/bpf: Cover small conntrack opts error writes", " - netfilter: nf_conntrack_helper: dynamically allocate struct", " nf_conntrack_helper", " - netfilter: nf_conntrack_pptp: move GRE specific cleanup to GRE tracker", " - netfilter: nf_conntrack_gre: fix gre keymap list corruption", " - netfilter: conntrack: check NULL when retrieving ct extension", " - netfilter: nf_conntrack_expect: use conntrack GC to reap expectations", " - netfilter: nf_conntrack_expect: store master_tuple in expectation", " - netfilter: nf_conntrack_expect: run expectation eviction with no helper", " - netfilter: nft_ct: expectation timeouts are passed in milliseconds", " - netfilter: nf_conntrack_helper: cap maximum number of expectation at", " helper registration", " - cpuidle: Allow exit latency to exceed target residency", " - ASoC: SDCA: Validate written enum value in ge_put_enum_double()", " - ASoC: rt5575: Use __le32 for SPI burst write address", " - PCI: endpoint: pci-epf-vntb: Exclude reserved slots from db_valid_mask", " - net: ti: icssg: Fix XSK zero copy TX during application wakeup", " - net: lwtunnel: Drop skb metadata before LWT encapsulation", " - sctp: fix err_chunk memory leaks in INIT handling", " - net: dsa: mxl862xx: avoid unaligned 16-bit access in api_wrap", " - octeontx2-af: fix CGX debugfs RVU AF PCI reference leaks", " - geneve: gate GRO hint in geneve_gro_complete() on gs->gro_hint", " - geneve: validate inner network offset in geneve_gro_complete()", " - tools: ynl: build archives with $(AR)", " - net: enetc: fix potential divide-by-zero when num_vsi is zero", " - udp_tunnel: Pass struct sock to setup_udp_tunnel_sock().", " - tipc: avoid busy looping in tipc_exit_net()", " - bpf: Mask pseudo pointer values in verifier logs", " - bpf: Fix insn_aux_data leak on verifier err_free_env path", " - hwmon: (pmbus/core) Add support for NVIDIA nvidia195mv mode", " - hwmon: (pmbus/core) honor vrm_version in pmbus_data2reg_vid()", " - gpio: shared-proxy: always serialize with a sleeping mutex", " - drm/panthor: Always use the IRQ-safe variant when acquiring the fence", " lock", " - drm/panthor: Keep the reset work disabled until everything is", " initialized", " - drm/panthor: Fix panthor_pwr_unplug()", " - spi: rzv2h-rspi: Fix DMA transfer error handling for signal interruption", " - xen/pvcalls: bound backend response req_id before indexing rsp[]", " - afs: Remove setting of AS_RELEASE_ALWAYS for symlinks and mountpoints", " - afs: Fix directory inode initialisation order", " - afs: Use scoped_seqlock_read() rather than manually doing seqlock stuff", " - afs: Fix leak of ungot volume", " - iomap: release pages on atomic dio size mismatch", " - cachefiles: Fix double unlock in nomem_d_alloc error path", " - cachefiles: Fix file burial to take lock when unsetting S_KERNEL_FILE", " - drm/imagination: Fix returned size for DRM_IOCTL_PVR_DEV_QUERY", " - iio: dac: mcp47feb02: Fix passing uninitialized vref1_uV for no Vref1", " case", " - net/mlx5: LAG, replace pf array with xarray", " - net/mlx5: LAG, use xa_alloc to manage LAG device indices", " - net/mlx5: Lag: refactor representor reload handling", " - net/mlx5: E-Switch, add representor lifecycle lock", " - net/mlx5: Lag, avoid LAG and representor lock cycles", " - net/mlx5: LAG, factor out shared FDB code into dedicated file", " - net/mlx5: LAG, replace peer count check with direct peer lookup", " - net/mlx5: LAG, prepare for SD device integration", " - net/mlx5: LAG, replace mlx5_get_dev_index with LAG sequence number", " - net/mlx5: LAG, extend shared FDB API with group_id filter", " - net/mlx5: LAG, Fix off-by-one in single-FDB error rollback", " - ksmbd: fix multichannel binding and enforce channel limit", " - smb: client: preserve leading slash for POSIX absolute symlink targets", " - gpio: shared: make the voting mechanism adaptable", " - drm/i915/ltphy: Fix SSC Enablement bit in PORT_CLOCK_CTL", " - Bluetooth: 6lowpan: avoid untracked enable work", " - Bluetooth: btintel_pcie: Support Product level reset", " - [Config] Make BT_INTEL_PCIE depend on ACPI", " - Bluetooth: btintel_pcie: Add support for smart trigger dump", " - Bluetooth: btintel_pcie: Separate coredump work from RX work", " - Bluetooth: btintel_pcie: Refactor FLR to use device_reprobe()", " - Bluetooth: ISO: fix malformed ISO_END/CONT handling", " - accel/amdxdna: Prevent PM resume deadlock in hwctx_sync_debug_bo()", " - accel/amdxdna: Fix VMA access race", " - net: rnpgbe: fix mailbox endianness and remove pointer casts", " - drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE", " - smb: client: fix busy dentry warning on unmount after DIO", " - drm/fb-helper: Only consider active CRTCs for vblank sync", " - ethtool: rss: Fix hfunc and input_xfrm parsing on big endian", " - drm/imagination: make pvr_fw_trace_init_mask_ops static", " - VDUSE: avoid leaking information to userspace", " - ASoC: SOF: ipc4-control: Validate notification payload size", " - arm64: dts: renesas: ironhide: Describe inline ECC carveouts", " - arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers", " - KVM: s390: vsie: Fix allocation of struct vsie_rmap", " - KVM: s390: vsie: Add missing radix_tree_preload() in", " _gaccess_shadow_fault()", " - KVM: s390: Add some useful mask macros", " - KVM: s390: vsie: Fix rmap handling in _do_shadow_crste()", " - KVM: s390: vsie: Fix redundant rmap entries", " - KVM: s390: vsie: Use mmu cache to allocate rmap", " - KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory", " - KVM: TDX: Reject concurrent change to CPUID entry count", " - ASoC: SOF: topology: fix memory leak in snd_sof_load_topology", " - netfilter: nft_fib: reject fib expression on the netdev egress hook", " - netfilter: nf_conntrack_sip: remove net variable shadowing", " - netfilter: nf_conntrack_sip: validate skb_dst() before accessing it", " - gpu/buddy: bail out of try_harder when alignment cannot be honoured", " - backlight: ktd2801: Enable BL_CORE_SUSPENDRESUME", " - cxl: Fix CXL_HEADERLOG_SIZE to match RAS Capability size", " - pinctrl: renesas: rzg2l: Use -ENOTSUPP instead of -EOPNOTSUPP", " - remoteproc: xlnx: Check remote core state", " - mm/sparse-vmemmap: fix vmemmap accounting underflow", " - mm/huge_memory: preserve pmd_swp_uffd_wp on device-private PMD downgrade", " - fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race", " - fs/proc/task_mmu: do not warn on seeing non-migration pmd entry", " - kho: make sure scratch size is always aligned by CMA_MIN_ALIGNMENT_BYTES", " - mtd: maps: vmu-flash: fix fault in unaligned fixup", " - dmaengine: dw-edma-pcie: Reject devices without driver data", " - dmaengine: sh: rz-dmac: Move interrupt request after everything is set", " up", " - platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8D26)", " - platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8E35)", " - spi: imx: reconfigure for PIO when DMA cannot be started", " - ovl: use linked upper dentry in copy-up tmpfile", " - can: bcm: add locking when updating filter and timer values", " - can: bcm: extend bcm_tx_lock usage for data and timer updates", " - can: bcm: fix CAN frame rx/tx statistics", " - can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()", " - can: bcm: fix stale rx/tx ops after device removal", " - can: bcm: track a single source interface for ANYDEV timeout/throttle", " ops", " - can: bcm: validate frame length in bcm_rx_setup() for RTR replies", " - can: bcm: add missing device refcount for CAN filter removal", " - selftests/bpf: Cover negative buffer pointer offsets", " - dm: avoid leaking the caller's thread keyring via the table device file", " - dma-buf: protected fence ops by RCU v8", " - dma-fence: use correct callback in dma_fence_timeline_name()", " - accel/amdxdna: reject command submission on devices without a submit op", " - accel/amdxdna: reject user command submission without a command BO", " - accel/amdxdna: Use caller client for debug BO sync", " - fs/resctrl: Fix use-after-free during unmount", " - mmc: vub300: fix use-after-free on probe failure", " - octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF", " - ksmbd: fix stack buffer overflow in multichannel session-key copy", " - netfilter: nfnetlink_cthelper: cap to maximum number of expectation per", " master", " - netfilter: nfnetlink_cthelper: cap to maximum number of expectation per", " master on updates", " - riscv: vdso: Always declare vdso_start symbols", " - ata: libata-core: Add NOLPM quirk for PNY CS900 1TB SSD", " - ata: libata-core: Reject an invalid concurrent positioning ranges count", " - net: ipa: fix SMEM state handle leaks in SMP2P init", " - amdkfd: properly free secondary context id", " - pmdomain: imx93-blk-ctrl: Extract PHY as shared domain for DSI/CSI", " - pmdomain: mediatek: Fix possible nullptr KP in HWV cleanup/on-check", " - arch/riscv: vdso: remove CFI landing pad from rt_sigreturn", " - reset: imx7: Correct polarity of MIPI CSI resets on i.MX8MQ", " - powerpc/uaccess: correct check for CONFIG_PPC_E500 in", " mask_user_address()", " - wifi: mac80211: validate extension-frame layout before RX", " - xfs: factor out a xfs_zone_mark_free helper", " - xfs: add newly added RTGs to the free pool in growfs", " - liveupdate: validate session type before performing operation", " - posix-timers: Expand timer_[re]arm() callbacks with a boolean return", " value", " - posix-cpu-timers: Prevent UAF caused by non-leader exec() race", " - Revert \"gpib: cb7210: Fix region leak when request_irq fails\"", " - Upstream stable to v6.18.40, v7.1.5", " * Resolute update: upstream stable patchset 2026-08-20 (LP: #2164666) //", " CVE-2023-20585", " - 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", " * [Regression] Laptop fails to power off completely when HDMI is connected", " in kernel 7.0.0-28 (LP: #2163121) // CVE-2026-68364", " - drm/amd/display: fix NULL ptr deref in ISM delayed work", " - drm/amd/display: Fix ISM teardown crash from NULL dc dereference", " - drm/amd/display: Fix ISM dc_lock deadlock during suspend", " * CVE-2026-72064", " - net: mana: Sync page pool RX frags for CPU", " * CVE-2026-72065", " - net: mana: Validate the packet length reported by the NIC", " * CVE-2026-72098", " - dm-verity-fec: replace {MAX,MIN}_RSN with {MIN,MAX}_ROOTS", " - dm-verity: fix buffer overflow in FEC calculation", " * CVE-2026-72248", " - netfilter: flowtable: support IPIP tunnel with direct xmit", " - netfilter: flowtable: use correct direction to set up tunnel route", " * CVE-2026-72249", " - netfilter: flowtable: use dst in this direction when pushing IPIP header", " * CVE-2026-72287", " - KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\"", " checks", " * CVE-2026-72329", " - net/liquidio: drop cached VF pci_dev LUT", " * CVE-2026-72355", " - netfs: Fix barriering when walking subrequest list", " * CVE-2026-72412", " - s390/mm: Fix handling of _PAGE_UNUSED pte bit", " * CVE-2026-72417", " - netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto()", " * CVE-2026-72442", " - netfilter: flowtable: fix and simplify IP6IP6 tunnel handling", " * CVE-2026-72463", " - xfrm: Fix dev use-after-free in xfrm async resumption", " * CVE-2026-72477", " - fs/ntfs3: call _ntfs_bad_inode() when failing to rename", " * CVE-2026-72493", " - net: serialize netif_running() check in enqueue_to_backlog()", " * CVE-2026-72494", " - RDMA/irdma: Replace waitqueue and flag with completion", " * CVE-2026-72496", " - RDMA/bnxt_re: Proper rollback if the ioremap fails", " * CVE-2026-74269", " - bnxt: fix head underflow on XDP head-grow", " * CVE-2026-74350", " - ocfs2: validate fast symlink target during inode read", " * CVE-2026-72495", " - RDMA/bnxt_re: Avoid repeated requests to allocate WC pages", " * CVE-2026-72501", " - RDMA/bnxt_re: Initialize dpi variable to zero", " * CVE-2026-72278", " - KVM: arm64: nv: Re-translate VNCR before injecting abort", " * CVE-2026-68083", " - ksmbd: fix path resolution in ksmbd_vfs_kern_path_create", " * CVE-2026-68457", " - ksmbd: use opener credentials for FSCTL mutations", " * CVE-2026-68476", " - ipvs: reload ip header after head reallocation", " * CVE-2026-68477", " - ipvs: fix more places with wrong ipv6 transport offsets", " * CVE-2026-72014", " - drbd: reject data replies with an out-of-range payload size", " * CVE-2026-72020", " - ipvs: reset full ip_vs_seq structs in ip_vs_conn_new", " * CVE-2026-72033", " - orangefs: keep the readdir entry size 64-bit in fill_from_part()", " * CVE-2026-72041", " - espintcp: use sk_msg_free_partial to fix partial send", " * CVE-2026-72046", " - gve: fix header buffer corruption with header-split and HW-GRO", " * CVE-2026-72069", " - locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()", " * CVE-2026-72083", " - scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE", " * CVE-2026-72084", " - scsi: target: Bound PR-OUT TransportID parsing to the received buffer", " * CVE-2026-72085", " - scsi: xen: scsiback: Free unsubmitted command instead of double-putting", " it", " * CVE-2026-72129", " - nvmet-rdma: handle inline data with a nonzero offset", " * CVE-2026-72130", " - nvmet-auth: reject short AUTH_RECEIVE buffers", " * CVE-2026-64551", " - sctp: validate STALE_COOKIE cause length before reading staleness", " * CVE-2026-72137", " - xfrm: nat_keepalive: avoid double free on send error", " * CVE-2026-72139", " - tcp: defer md5sig_info kfree past RCU grace period in tcp_connect", " * CVE-2026-72191", " - ntfs3: validate split-point offset in indx_insert_into_buffer", " * CVE-2026-72192", " - ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head", " * CVE-2026-72194", " - fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow", " * CVE-2026-72217", " - SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing", " * CVE-2026-72220", " - sunrpc: harden rq_procinfo lifecycle to prevent double-free", " * CVE-2026-72221", " - sunrpc: wait for in-flight TLS handshake callback when cancel loses race", " * CVE-2026-72222", " - sunrpc: pin svc_xprt across the asynchronous TLS handshake callback", " * CVE-2026-72226", " - batman-adv: tt: prevent TVLV OOB check overflow", " * CVE-2026-72234", " - batman-adv: access unicast_ttvn skb->data only after skb realloc", " * CVE-2026-72251", " - netfilter: nf_nat_sip: reload possible stale data pointer", " * CVE-2026-72277", " - KVM: arm64: nv: Inject SEA if kvm_translate_vncr() can't resolve PFN", " - KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory", " * CVE-2026-72279", " - KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR", " * CVE-2026-72288", " - KVM: arm64: vgic: Handle race between interrupt affinity change and LPI", " disabling", " * CVE-2026-72289", " - KVM: arm64: vgic: Check the interrupt is still ours before migrating it", " * CVE-2026-72296", " - net: ife: require ETH_HLEN to be pullable in ife_decode()", " * CVE-2026-72299", " - tipc: restrict socket queue dumps in enqueue tracepoints", " * CVE-2026-72317", " - SUNRPC: pin upper rpc_clnt across the TLS connect_worker", " * CVE-2026-72318", " - cifs: validate DFS referral string offsets", " * CVE-2026-72319", " - ipvs: fix PMTU for GUE/GRE tunnel ICMP errors", " - ipvs: ensure inner headers in ICMP errors are in headroom", " * CVE-2026-72320", " - netfilter: nft_lookup: fix catchall element handling with inverted", " lookups", " * CVE-2026-72322", " - ipv6: mcast: Fix potential UAF in MLD delayed work", " * CVE-2026-72323", " - ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()", " * CVE-2026-64541", " - net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket", " * CVE-2026-72339", " - qede: fix off-by-one in BD ring consumption on build_skb failure", " * CVE-2026-72348", " - netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop", " * CVE-2026-72351", " - gue: validate REMCSUM private option length", " * CVE-2026-72366", " - netfs: Fix netfs_create_write_req() to handle async cache object", " creation", " * CVE-2026-72381", " - ksmbd: fix use-after-free of fp->owner.name in durable handle owner", " check", " * CVE-2026-72393", " - eth: fbnic: don't cache shinfo across skb realloc", " * CVE-2026-72398", " - sctp: add INIT verification after cookie unpacking", " * CVE-2026-72399", " - net: enetc: check the number of BDs needed for xdp_frame", " * CVE-2026-64530", " - net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle", " * CVE-2026-72422", " - ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2", " NEGOTIATE", " * CVE-2026-72429", " - ipv6: ioam: fix type confusion of dst_entry", " * CVE-2026-72436", " - 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", " * CVE-2026-72451", " - xfrm: Fix xfrm state cache insertion race", " * CVE-2026-72466", " - xprtrdma: Fix bcall rep leak and unbounded peek", " * CVE-2026-72472", " - nfs: use nfsi->rwsem to protect traversal of the file lock list", " * CVE-2026-72473", " - 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", " * CVE-2026-72491", " - net/9p: fix race condition on rdma->state in trans_rdma.c", " * CVE-2026-72495 // CVE-2026-72501", " - RDMA/bnxt_re: Move the UAPI methods to a dedicated file", " * CVE-2026-74255", " - tipc: fix UAF in tipc_l2_send_msg()", " * CVE-2026-74267", " - net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek", " before restoring qlen", " * CVE-2026-74268", " - tcp: clear sock_ops cb flags before force-closing a child socket", " * CVE-2026-74287", " - sctp: validate embedded address parameter length", " * CVE-2026-74310", " - vhost/net: complete zerocopy ubufs only once", " * CVE-2026-74345", " - RDMA/siw: Fix endpoint/socket association handling", " * CVE-2026-74361", " - nvme: fix FDP fdpcidx bounds check", " * CVE-2026-74376", " - md/raid10: reset read_slot when reusing r10bio for discard", " * CVE-2026-74384", " - nvme-multipath: fix flex array size in struct nvme_ns_head", " * CVE-2026-74394", " - RDMA/srpt: fix integer overflow in immediate data length check", " * CVE-2026-74398", " - ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD", " * CVE-2026-74401", " - dlm: fix add msg handle in send_queue ordered", " * CVE-2026-74406", " - vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().", " * CVE-2026-74427", " - afs: Fix netns teardown to cancel the preallocation charger", " - afs: Fix further netns teardown to cancel the preallocation charger", " * CVE-2026-74428", " - rxrpc: Fix double unlock in rxrpc_recvmsg()", " * CVE-2026-74433", " - rxrpc: Fix UAF in rxgk_issue_challenge()", " * CVE-2026-74434", " - rxrpc: Don't move a peeked OOB message onto the pending queue", " * CVE-2026-74436", " - rxrpc: serialize kernel accept preallocation with socket teardown", " * CVE-2026-64535", " - nvmet-tcp: Fix potential UAF when ddgst mismatch", " * CVE-2026-74439", " - iommu/vt-d: Clear Present bit before tearing down scalable-mode context", " entry", " * CVE-2026-64534", " - nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error", " path", "" ], "package": "linux-riscv-7.0", "version": "7.0.0-38.38.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2165483, 2165484, 2165407, 2166547, 2166443, 2166356, 2165872, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165407, 2165040, 2161748, 2163508, 2163214, 2162904, 2162045, 2164967, 2160082, 2164504, 2156316, 2164716, 2164516, 2163375, 2162803, 2163062, 2132119, 2163293, 2160200, 2158858, 2162704, 2162695, 2164666, 2164666, 2163121 ], "author": "Sarah Emery ", "date": "Sun, 27 Sep 2026 00:11:21 +0200" } ], "notes": "linux-modules-7.0.0-38-generic version '7.0.0-38.38.1~24.04.1' (source package linux-riscv-7.0 version '7.0.0-38.38.1~24.04.1') was added. linux-modules-7.0.0-38-generic version '7.0.0-38.38.1~24.04.1' has the same source package name, linux-riscv-7.0, as removed package linux-headers-7.0.0-34-generic. As such we can use the source package version of the removed package, '7.0.0-34.34.1~24.04.1', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-riscv-7.0-headers-7.0.0-38", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": null }, "to_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-38.38.1~24.04.1", "version": "7.0.0-38.38.1~24.04.1" }, "cves": [ { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-68105", "url": "https://ubuntu.com/security/CVE-2026-68105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix kernel panic during driver load failure Avoid kernel panic if MES init fails during driver load. The KIQ ring is falsely marked as ready as ASICs that use MES, KIQ is owned by MES. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] Call Trace: gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280 __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53 (cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68109", "url": "https://ubuntu.com/security/CVE-2026-68109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68114", "url": "https://ubuntu.com/security/CVE-2026-68114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit e4d99e04b2e9b13b97d3b17804c735f62689db23)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68431", "url": "https://ubuntu.com/security/CVE-2026-68431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate minimum PDU size for transform requests The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68138", "url": "https://ubuntu.com/security/CVE-2026-68138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: serialize qdisc_rtab_list against concurrent get/put qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68082", "url": "https://ubuntu.com/security/CVE-2026-68082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix two unsafe bare decodes in decode_lockers() decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-08 10:16:00 UTC" }, { "cve": "CVE-2026-68159", "url": "https://ubuntu.com/security/CVE-2026-68159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68163", "url": "https://ubuntu.com/security/CVE-2026-68163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_vma_mapped: fix device-private PMD handling Commit 65edfda6f3f2 (\"mm/rmap: extend rmap and migration support device-private entries\") introduced the concept of device-private PMD entries, but did not correctly update the rmap walk code to account for them. As a result, when page_vma_mapped_walk() encounters device-private PMD entries, it takes no action other than to acquire the PMD lock and exit. However this is highly problematic for two reasons - firstly, device private entries possess a PFN so check_pmd() needs to be called to ensure an overlapping PFN range. Secondly, and more importantly, if PVMW_MIGRATION is set the caller assumes the returned entry is a migration entry, resulting in memory corruption when the caller tries to interpret the device private entry as such. In addition, commit 146287290023 (\"mm/huge_memory: implement device-private THP splitting\") allowed device private PMDs to be split like THP mappings, but again did not update this code path. As a result, we might race a PMD split prior to acquiring the PMD lock. This patch addresses all of these issues by invoking check_pmd(), ensuring PMVW_MIGRATION is not set and checks whether a split raced us we do for PMD THP and migration entries. Instead of checking for a subset of the cases after taking the pmd_lock(), put device-private along with pmd_trans_huge() and pmd_is_migration_entry(). Also remove thp_migration_supported() as it is already guarded by pmd_is_migration_entry(). [akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68166", "url": "https://ubuntu.com/security/CVE-2026-68166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: prevent registration of special VMAs Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68170", "url": "https://ubuntu.com/security/CVE-2026-68170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix stale skb->sk reference on subflow close The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68177", "url": "https://ubuntu.com/security/CVE-2026-68177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Delay module ref count for \"enable_event\" trigger Triggers are now delayed from freeing, but can still be triggered until after the RCU grace period has ended. The freeing of the enable_event data is put into the private_data_free() callback, but the put of the module refcount is done immediately. It is possible that if a module is removed that has an event that would enable (or disable) it is still active, it can read the data of the module after it is removed causing a use-after-free bug. Move the trace_event_put_ref() that releases the module into the delayed callback so that the module can not be removed until any reference to its events are finished.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68191", "url": "https://ubuntu.com/security/CVE-2026-68191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix NULL pointer dereference in rhash table destroy When unbinding the ath12k driver, kernel NULL pointer dereferences occur in irq_work_sync() called from rhashtable_destroy(). Two hash tables are affected: 1. ath12k_link_sta hash table in ath12k_base 2. ath12k_dp_link_peer hash table in ath12k_dp The issue happens because the destroy functions are called unconditionally in cleanup paths, but the hash tables are only initialized late in their respective init functions. If the device was never fully started or if the init functions failed before initializing the hash tables, the pointers will be NULL. The issues are always reproducible from a VM because the MSI addressing initialization is failing. Call trace for ath12k_link_sta_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_link_sta_rhash_tbl_destroy+0x19/0x40 [ath12k] ath12k_core_stop+0xe/0x80 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Call trace for ath12k_dp_link_peer_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_dp_link_peer_rhash_tbl_destroy+0x29/0x50 [ath12k] ath12k_dp_cmn_device_deinit+0x21/0x140 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Fix this by adding NULL checks before calling rhashtable_destroy() in both destroy functions. The NULL check approach was chosen because the rhashtable pointer serves as the initialization state indicator. The init can fail at various points, leaving some components uninitialized. Checking the pointer directly is simpler than adding separate state flags that would need synchronization.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64586", "url": "https://ubuntu.com/security/CVE-2026-64586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: drain bus_reset work on device removal brcmf_fw_crashed() and the debugfs \"reset\" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs \"reset\" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. 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-68208", "url": "https://ubuntu.com/security/CVE-2026-68208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: Fix the error code of devm_kzalloc() in vip_probe_slice() In vip_probe_slice(), the error check for devm_kzalloc() incorrectly uses PTR_ERR_OR_ZERO() which returns 0 for NULL pointer. Return -ENOMEM for devm_kzalloc() failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68224", "url": "https://ubuntu.com/security/CVE-2026-68224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mali-c55: Fix possible ERR_PTR in enable_streams The media_pad_remote_pad_unique() function returns either a valid pointer or an ERR_PTR() on failure (-ENOTUNIQ if multiple links are enabled, -ENOLINK if no connected pad is found). The return value was assigned directly to isp->remote_src and dereferenced in the next line without checking for errors, which could lead to an ERR_PTR dereference. Add proper error checking with IS_ERR() before dereferencing the pointer. Also set isp->remote_src to NULL on error to maintain consistency with other error paths in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68237", "url": "https://ubuntu.com/security/CVE-2026-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: fix indefinite fence wait during GPU reset pre_reset only force-completes fences of MAPPED queues. A queue in any other state (e.g. mid-eviction) keeps its last_fence pending; after a GPU reset that fence never signals, so the eviction/suspend worker and process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and wedge the machine: INFO: task kworker/6:28 blocked for more than 120 seconds. Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu] Call Trace: dma_fence_wait_timeout+0x7e/0x130 amdgpu_userq_evict+0x67/0x140 [amdgpu] amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu] process_scheduled_works+0xa6/0x420 Force-complete every queue's fence regardless of state. The unmap and mark-hung step stays gated on MAPPED, since unmapping a queue that is not mapped is invalid. (cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68240", "url": "https://ubuntu.com/security/CVE-2026-68240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: publish dpagemap early to avoid device mapping leak on error drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68242", "url": "https://ubuntu.com/security/CVE-2026-68242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix NULL deref on sched_engine alloc failure Avoid using intel_context_put() before intel_context_init() in execlists_create_virtual() as the kref_put() inside would lead to NULL deref on the IOCTL path when sched_engine allocation fails. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68254", "url": "https://ubuntu.com/security/CVE-2026-68254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: require valid min/max vfreq for VRR Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68436", "url": "https://ubuntu.com/security/CVE-2026-68436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use kvzalloc to allocate struct dc struct dc has grown large over time (most of it the two inlined dc_scratch_space copies) and now sits close to the page allocator's 4 MiB contiguous allocation limit. Its actual size is not fixed by the source alone, it also depends on the compiler and the .config, so it can easily cross 4 MiB, e.g. with a newer GCC or a config change. dc_create() allocates it with kzalloc(). Once struct dc exceeds 4 MiB the request is rounded up to order 11 (8 MiB), which is above MAX_PAGE_ORDER, so the page allocator warns and returns NULL. dc_create() then fails, DM init fails and amdgpu probe aborts with -EINVAL: WARNING: mm/page_alloc.c:5197 at __alloc_frozen_pages_noprof+0x2f9/0x380 dc_create+0x38/0x660 [amdgpu] amdgpu_dm_init+0x2d9/0x510 [amdgpu] dm_hw_init+0x1b/0x90 [amdgpu] amdgpu_device_init.cold+0x150d/0x1e13 [amdgpu] amdgpu_driver_load_kms+0x19/0x80 [amdgpu] amdgpu_pci_probe+0x1e2/0x4c0 [amdgpu] dc_create() then returns NULL and DM init fails, which aborts the whole GPU init and makes amdgpu probe fail with -EINVAL (\"hw_init of IP block failed -22\"), leaving the display unusable. The subsequent amdgpu_irq_put() warnings during teardown are just fallout of unwinding a half-initialized device. struct dc is a software-only bookkeeping structure that is never handed to hardware DMA and is only ever kept as an opaque pointer, so it does not require physically contiguous memory. Allocate it with kvzalloc() (and free it with kvfree()) so that the allocator can fall back to vmalloc() when a contiguous allocation of that size is not available, which also avoids the MAX_PAGE_ORDER warning entirely. v2: - Rebase to amd-staging-drm-next. (cherry picked from commit 991e0516a8072f2292681c6ae98a924ab0e32575)", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68447", "url": "https://ubuntu.com/security/CVE-2026-68447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size from hardware without bounding it to the allocated BO region. If the HW field is larger than the queue's control stack allocation, memcpy reads past the BO into adjacent GTT memory and can leak kernel data to userspace. Store the page-aligned control stack BO size in mqd_manager and clamp checkpoint copies and reported checkpoint sizes to min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound for multi-XCC v9.4.3 checkpoint layout. (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3)", "cve_priority": "high", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68264", "url": "https://ubuntu.com/security/CVE-2026-68264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: Reset current_op in xe_pt_update_ops_init() xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it. After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind. Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry. Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(). v2 (Matt): - Add details in commit message. - Add Fixes tag and Cc to stable@vger.kernel.org (cherry picked from commit 046045543e530605c441063535e7dca0075369a6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68265", "url": "https://ubuntu.com/security/CVE-2026-68265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO's tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference (cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68267", "url": "https://ubuntu.com/security/CVE-2026-68267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists Unconditionally whitelisting OA registers is a security violation. Set RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers don't get whitelisted by default after probe, gt reset, resume and engine reset. (cherry picked from commit 90511bdcfda97211c01f1d945d4ea616578d8fca)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68273", "url": "https://ubuntu.com/security/CVE-2026-68273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68274", "url": "https://ubuntu.com/security/CVE-2026-68274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix buffer overflow in steered register list allocation The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt->fuse_topo.g_dss_mask, ...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68283", "url": "https://ubuntu.com/security/CVE-2026-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free freeing trigger private data Commit 61d445af0a7c (\"tracing: Add bulk garbage collection of freeing event_trigger_data\") moved the kfree() of event_trigger_data to a kthread that runs tracepoint_synchronize_unregister() before freeing. That removed the synchronization the trigger .free callbacks used to get implicitly and inline from trigger_data_free(). event_hist_trigger_free(), event_hist_trigger_named_free() and event_enable_trigger_free() free their satellite data (hist_data, cmd_ops, enable_data) right after trigger_data_free() returns. With the synchronization now deferred to the kthread, a concurrent tracepoint handler can still reach that data through the list_del_rcu()'d trigger, causing a use-after-free. The histogram teardown must stay synchronous: remove_hist_vars() and unregister_field_var_hists() have to detach a synthetic event from the histogram before the trigger-removal write returns, otherwise a following command races in and the synthetic-event removal fails with -EBUSY, as the trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait with the correct barrier - tracepoint_synchronize_unregister(), matching the free kthread - before freeing. The enable trigger has no such synchronous requirement, and a blocking synchronize there would re-serialize the path that commit deliberately deferred. Give it an optional private_data_free() callback that the free kthread runs after its grace period, and free enable_data from there.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68286", "url": "https://ubuntu.com/security/CVE-2026-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68287", "url": "https://ubuntu.com/security/CVE-2026-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix size calculations for 64-bit attributes net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68288", "url": "https://ubuntu.com/security/CVE-2026-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68289", "url": "https://ubuntu.com/security/CVE-2026-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68291", "url": "https://ubuntu.com/security/CVE-2026-68291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix max_vport related crash on allocation error during init Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000 [ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000 [ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20 [ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000 [ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0 [ 320.417385] PKRU: 55555554 [ 320.417398] Call Trace: [ 320.417412] [ 320.417429] pci_device_remove+0x42/0xb0 [ 320.417459] device_release_driver_internal+0x1a9/0x210 [ 320.417492] driver_detach+0x4b/0x90 [ 320.417516] bus_remove_driver+0x70/0x100 [ 320.417539] pci_unregister_driver+0x2e/0xb0 [ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0 [ 320.417592] ? kmem_cache_free+0x31e/0x550 [ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190 [ 320.417644] ? do_syscall_64+0x38/0x6b0 [ 320.417665] do_syscall_64+0xc8/0x6b0 [ 320.417683] ? clear_bhb_loop+0x30/0x80 [ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 320.417727] RIP: 0033:0x7f963bb30beb", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68303", "url": "https://ubuntu.com/security/CVE-2026-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hvs/v3d: Fix null dereference in unbind The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68312", "url": "https://ubuntu.com/security/CVE-2026-68312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and cifs_close_deferred_file_under_dentry(), when a pending deferred close is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to add the file to the local processing list may fail under memory pressure. The loop breaks immediately, but the cancelled work is no longer pending (it would have called _cifsFileInfo_put()), and the cfile is never added to file_head for processing. The cifsFileInfo reference and the open server handle both leak. Fix by saving the cfile that failed allocation in a local variable, breaking as before, and calling _cifsFileInfo_put() on it after releasing the lock. Any files later in the iteration are unaffected since their deferred work is still pending and will fire normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68316", "url": "https://ubuntu.com/security/CVE-2026-68316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Fix element size accounting for cmd stream validation There are 2 issues with the element size handling in the command stream validation which result in too small of a size calculated when the element size is 16/32/64 bits. For NHWC format, the element size is simply missing from the calculation. The bitfield for the element size is different between IFM/IFM2 and OFM. IFM and IFM2 encode the precision in parameter bits 2:3, while OFM uses bits 1:2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68440", "url": "https://ubuntu.com/security/CVE-2026-68440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix heap overflow when reading module EEPROM txgbe_read_eeprom_hostif() always copies round_up(length, 4) bytes into the caller buffer, which ethtool allocates with exactly 'length' bytes. A non-4-aligned length therefore causes an out-of-bounds write. Copy only the remaining bytes on the final dword instead.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68323", "url": "https://ubuntu.com/security/CVE-2026-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: serialize udp bearer replicast list updates tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68441", "url": "https://ubuntu.com/security/CVE-2026-68441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected. This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d (\"bpf: add bpf_redirect() helper\"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available. commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs. Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a wrapper around tcf_classify() for use by qdisc classify functions and tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT, the wrapper converts it to TC_ACT_SHOT, dropping the packet rather than letting it continue silently. Dropping is preferred over letting the packet through because the user immediately sees packet loss. Silently passing the packet through would hide the problem and leave the user wondering why their redirect is not working. The clsact fast path, tc_run() continues to call tcf_classify() directly and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by sch_handle_egress/ingress() calling skb_do_redirect() as before.", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68337", "url": "https://ubuntu.com/security/CVE-2026-68337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject redirect helpers without a bpf_net_context The bpf_redirect*() helpers and skb_do_redirect() obtain the per-task bpf_redirect_info via bpf_net_ctx_get_ri(), which dereferences the current->bpf_net_context unconditionally. That context is established on the paths that run tc BPF such as sch_handle_{ingress,egress}(), *except* for the case where {cls,act}_bpf was attached to a proper qdisc. A program running from there reaches the NULL deref in two ways: * It calls bpf_redirect() directly, which dereferences the context at the top of the helper: tc qdisc add dev eth0 root handle 1: red limit 1MB min 10KB max 20KB \\ avpkt 1000 burst 100 qevent early_drop block 10 tc filter add block 10 pref 1 bpf obj redirect.o * It simply returns TC_ACT_REDIRECT without helper call: tcf_qevent_handle() then dispatches to skb_do_redirect(), which dereferences the context Rather than extending bpf_net_context management into the qdisc path, make the redirect helpers refuse to operate when no context exists, and have tcf_qevent_handle() drop a TC_ACT_REDIRECT verdict instead of calling skb_do_redirect(). Previous behaviour was a crash, so nothing regresses by not supporting it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68345", "url": "https://ubuntu.com/security/CVE-2026-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm_mpam: guard MBWU state before adding it to garbage __destroy_component_cfg() adds each RIS mbwu_state object to the MPAM garbage list when destroying component configuration. However, mbwu_state is allocated per RIS and only for RISes with MBWU monitors. A component can therefore have comp->cfg allocated while some RISes still have ris->mbwu_state set to NULL. Passing a NULL mbwu_state to add_to_garbage() dereferences the NULL pointer inside the macro. Skip RISes that do not have an mbwu_state object before adding them to the garbage list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68347", "url": "https://ubuntu.com/security/CVE-2026-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68375", "url": "https://ubuntu.com/security/CVE-2026-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle partially initialized auxiliary devices bnxt_aux_devices_init() calls auxiliary_device_init() before all fields used by bnxt_aux_dev_release() are initialized. After auxiliary_device_init() succeeds, later errors must unwind with auxiliary_device_uninit(), which invokes the release callback. The release callback assumes that aux_priv->id, aux_priv->edev, edev->net and edev->ulp_tbl are all populated. If allocation fails after auxiliary_device_init(), the release path can otherwise dereference or clear partially initialized state. Allocate and attach the bnxt_en_dev and ULP table before calling auxiliary_device_init(), so the release callback only sees a fully initialized auxiliary private object. If auxiliary_device_init() itself fails, free those allocations directly because device_initialize() has not run and the release callback will not be invoked. 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-68382", "url": "https://ubuntu.com/security/CVE-2026-68382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Hold device ref until queue teardown completes GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock. Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending. Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work. With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. Replace the fini wait with an assertion and remove the unused fini_wq. v2: - Rebase v3: - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt) - Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt) - Drop separate deferred drm_dev_put worker. - Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini(). v4: - Replace the guc_submit_sw_fini() wait with an assertion and remove the now-unused fini_wq. (sashiko) v5: - Move destroy work to a module-lifetime Xe workqueue instead of system_dfl_wq. (Matt) - Flush the module-lifetime destroy workqueue during PCI remove to preserve the old device-remove wait semantics. v6: - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid letting it outlive the xe_device/drm_device. (Sashiko) - Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work can be queued from the reclaim path. v7: - Drop the per-device xe->destroy_wq and use the module-level destroy WQ for SVM pagemap destroy as well. (Matt) - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*() helpers because the WQ is no longer exec-queue specific. (Matt) v8: - Rebase. v9: - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM destroy_wq because it can be queued from reclaim and embeds the dev_pagemap used by devres teardown. (Sashiko) - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM from it. - Update the module-WQ kdoc to document the GuC/SVM split. v10: - Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the workqueue allocation warning. v11: - Drop the SVM pagemap destroy comment as it was revision-specific. (Thomas) v12: - Rebase. (cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68383", "url": "https://ubuntu.com/security/CVE-2026-68383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Keep scheduler timeline name alive The scheduler keeps a pointer to the timeline name, but q->name is freed with the exec queue while scheduler fences can still reference it. Store the name in struct xe_guc_exec_queue so it shares the scheduler's RCU-deferred lifetime. (cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68390", "url": "https://ubuntu.com/security/CVE-2026-68390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups hci_conn_params_lookup requires hdev->lock be held, otherwise the list iteration or param access is not safe. Hold hdev->lock for params lookups in hci_sync.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-2026-68404", "url": "https://ubuntu.com/security/CVE-2026-68404", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: use wiphy work for socket owner autodisconnect nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68367", "url": "https://ubuntu.com/security/CVE-2026-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: synchronize delayed set_alt with teardown The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68095", "url": "https://ubuntu.com/security/CVE-2026-68095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse-uring: fix race between registration and connection abortion This fixes this race: - thread a: io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref yet - thread b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() is a no-op due to queue ref being 0 - thread a: grabs the queue_ref, queue_ref is now 1, rest of fuse_uring_do_register() logic executes - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs and calls \"wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);\" The abort/unmount thread will hang indefinitely in unkillable state as nothing will decrement queue_refs or wake stop_waitq, and the ring, queue, and ent are leaked. Fix this by checking fch->connected under fch->lock after the created ent has grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either release the queue ref and wake up stop_waitq (in case fuse_chan_wait_aborted() is already waiting) in fuse_uring_do_register() when we detect !fch->connected, or if the connection is aborted after the check, it is guaranteed that the async teardown worker will be running in the background cleaning up ents and decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-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-68173", "url": "https://ubuntu.com/security/CVE-2026-68173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: wait on ublk_dev_ready() instead of ub->completion ub->completion is only re-armed by a successful START_USER_RECOVERY. If the ublk server sends END_USER_RECOVERY without one - e.g. its START failed with -EBUSY and the error was ignored - the wait is satisfied by the stale completion of the previous recovery cycle, and the device is marked LIVE and the requeue list kicked while the FETCH stream is still running and ubq->canceling is still set. The kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it again via __ublk_abort_rq(), and after the last FETCH clears ->canceling nothing ever kicks the requeue list again: the request is stranded there while holding its tag. If it is the flush machinery's flush_rq, every subsequent fsync piles up in uninterruptible sleep and teardown hangs on tag draining. This matches a report of a lost PREFLUSH with ext4 on top of ublk after daemon crash recovery. ub->completion is an edge-triggered latch used as a proxy for the level condition \"every queue has fetched all I/O commands\", which can regress (F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop it and wait on the real condition instead: the new helper ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then re-checks it under ub->mutex, waiting again on regression, and returns with the mutex held and readiness guaranteed. Readiness becomes true in the same ub->mutex critical section that clears the last queue's ->canceling, so END_USER_RECOVERY marks the device LIVE and kicks the requeue list strictly after ->canceling clears. The wait stays interruptible, so a server whose daemon died can still be signalled out. For ublk_ctrl_start_dev() this replaces the fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting until the device is ready again.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68113", "url": "https://ubuntu.com/security/CVE-2026-68113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68118", "url": "https://ubuntu.com/security/CVE-2026-68118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: challenge ACK for non-exact RST in SYN-RECEIVED The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68120", "url": "https://ubuntu.com/security/CVE-2026-68120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtase: Workaround for TX hang caused by hardware packet parsing The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission.", "cve_priority": "medium", "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-68122", "url": "https://ubuntu.com/security/CVE-2026-68122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix peer refcount leak in TCP error paths When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&peer->tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object. The race window: CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error): ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2 schedule_work() <- queued schedule_work() <- NO-OP (work already pending) ovpn_tcp_peer_del_work runs: ovpn_peer_del() ovpn_peer_put() <- refcnt+1 <- peer never freed Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68128", "url": "https://ubuntu.com/security/CVE-2026-68128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: reject out-of-range ptype in ice_parser_profile_init set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from providing ptype >= 1024 through VIRTCHNL, resulting in a write past the end of the bitmap and a kernel page fault. Reproduced with a custom kernel module injecting a crafted VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1. crash_parser: ice_parser_profile_init @ ffffffffc0d61b60 crash_parser: setting ptype=0xffff (max valid=1023) crash_parser: calling ice_parser_profile_init -- expect OOB crash! BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace: ? __pfx_ice_parser_profile_init+0x10/0x10 [ice] crash_init+0x127/0xff0 [crash_parser] do_one_initcall+0x45/0x310 do_init_module+0x64/0x270 init_module_from_file+0xcc/0xf0 idempotent_init_module+0x17b/0x280 __x64_sys_finit_module+0x6e/0xe0 Bail out early with -EINVAL when ptype is out of range.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68132", "url": "https://ubuntu.com/security/CVE-2026-68132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: super: fix emergency thaw deadlock on frozen block devices do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68133", "url": "https://ubuntu.com/security/CVE-2026-68133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP Call Trace during PTP release If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will result in the following PTP release call trace during driver unload: kernel BUG at lib/list_debug.c:52! ice_ptp_release+0x332/0x3c0 [ice] ice_deinit_features.part.0+0x10e/0x120 [ice] ice_remove+0x100/0x220 [ice] This was observed when passing PF1 through to a VM. ice_ptp_init() fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT. Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and returning without error, preventing the invalid state transition to ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from ICE_PTP_RESETTING after a failed rebuild.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68134", "url": "https://ubuntu.com/security/CVE-2026-68134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: ptp_s390: Add missing facility check Only register the physical clock when facility 28 is installed and PTFF QAF returns that PTFF QPT is available.", "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-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-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-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-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-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-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-68150", "url": "https://ubuntu.com/security/CVE-2026-68150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/super: fix emergency thaw double-unlock of s_umount do_thaw_all() iterates over all superblocks via __iterate_supers() with SUPER_ITER_EXCL, which acquires s_umount exclusively before calling the callback and releases it afterwards. However, the callback do_thaw_all_callback() calls thaw_super_locked() which unconditionally releases s_umount on every code path. This results in a second unlock attempt in __iterate_supers() that corrupts the rwsem state, triggering a DEBUG_RWSEMS warning: [ 182.601148] sysrq: Emergency Thaw of all frozen filesystems [ 182.601865] ------------[ cut here ]------------ [ 182.602375] DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff99b1011e5870, owner = 0x0, curr 0xffff99b101b06c80, list not empty [ 182.603817] WARNING: kernel/locking/rwsem.c:1412 at up_write+0xa3/0x170, CPU#2: kworker/2:1/53 [ 182.604578] Modules linked in: [ 182.604864] CPU: 2 UID: 0 PID: 53 Comm: kworker/2:1 Not tainted 7.2.0-rc4-00001-gbd3bd93ea98a-dirty #4 PREEMPT(lazy) [ 182.605711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014 [ 182.606417] Workqueue: events do_thaw_all [ 182.606750] RIP: 0010:up_write+0xaf/0x170 [ 182.607076] Code: 19 3a 92 48 0f 44 c2 48 8b 55 08 48 8b 55 00 4c 8b 45 08 48 8b 55 00 48 8d 3d ad 91 e0 01 48 8b 4d 20 50 48 c7 c6 f0 8c 26 92 <67> 48 0f b9 3a e8 d7 93 4e 00 58 eb 81 48 83 7f 18 00 48 c7 c2 8d [ 182.608563] RSP: 0018:ffffb670001d7e08 EFLAGS: 00010246 [ 182.609007] RAX: ffffffff92349e8d RBX: 0000000000000000 RCX: ffff99b1011e5870 [ 182.609595] RDX: 0000000000000000 RSI: ffffffff92268cf0 RDI: ffffffff92914d10 [ 182.610283] RBP: ffff99b1011e5870 R08: 0000000000000000 R09: ffff99b101b06c80 [ 182.610847] R10: ffff99b10139a808 R11: fefefefefefefeff R12: 0000000000000000 [ 182.611414] R13: ffffffff90cf74d0 R14: 0000000000000000 R15: ffff99b1011e5800 [ 182.612009] FS: 0000000000000000(0000) GS:ffff99b1eaaee000(0000) knlGS:0000000000000000 [ 182.612670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 182.613146] CR2: 00000000005c631c CR3: 00000000013ee000 CR4: 00000000000006f0 [ 182.613722] Call Trace: [ 182.613946] [ 182.614130] __iterate_supers+0x128/0x150 [ 182.614463] do_thaw_all+0x1b/0x30 [ 182.614759] process_scheduled_works+0xbb/0x3f0 [ 182.615150] ? __pfx_worker_thread+0x10/0x10 [ 182.615499] worker_thread+0x129/0x270 [ 182.615816] ? __pfx_worker_thread+0x10/0x10 [ 182.616201] kthread+0xe2/0x120 [ 182.616469] ? __pfx_kthread+0x10/0x10 [ 182.616792] ret_from_fork+0x15b/0x240 [ 182.617115] ? __pfx_kthread+0x10/0x10 [ 182.617426] ret_from_fork_asm+0x1a/0x30 [ 182.617761] [ 182.617968] ---[ end trace 0000000000000000 ]--- [ 182.618412] Emergency Thaw complete Fix this by switching to SUPER_ITER_UNLOCKED and acquiring s_umount in the callback via super_lock_excl() before calling thaw_super_locked(). This matches the locking pattern expected by thaw_super_locked() and eliminates the double unlock. While at it, remove the dead 'return;' at the end of do_thaw_all_callback().", "cve_priority": "low", "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-68152", "url": "https://ubuntu.com/security/CVE-2026-68152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: fix use-after-free in AMT delayed works When an AMT device is removed, pending delayed works can still access the freed amt_dev structure, which may result in kernel crashes or memory corruption. amt_dev_stop() cancels req_wq and discovery_wq with cancel_delayed_work_sync(), but these works can be scheduled again from event_wq after the cancellation. This allows delayed works to access the freed amt_dev structure after the netdev has been released. The following is a simple race scenario: CPU0 CPU1 amt_dev_stop() cancel_delayed_work_sync() amt_event_work() mod_delayed_work(req_wq) free netdev req_wq accesses freed amt_dev Use disable_delayed_work_sync() in amt_dev_stop() to prevent req_wq and discovery_wq from being queued again and wait for running work items to complete. The delayed works are disabled after initialization in amt_newlink() and enabled only when the device is successfully opened. This keeps the delayed work lifecycle synchronized with the lifetime of the AMT device.", "cve_priority": "high", "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-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-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-68168", "url": "https://ubuntu.com/security/CVE-2026-68168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix afs_edit_dir_remove() to get, not find, block 0 Fix afs_edit_dir_remove() to use afs_dir_get_block() to get block 0 rather than afs_dir_find_block() as the latter caches the found block in the afs_dir_iter and may[*] switch out the page it's on if another afs_dir_find_block() is done. This parallels what afs_edit_dir_add() does. [*] There's more than one block per page.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68169", "url": "https://ubuntu.com/security/CVE-2026-68169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: userspace: fix use-after-free in get_local_id In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a \"not found\" sentinel.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68172", "url": "https://ubuntu.com/security/CVE-2026-68172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: make huge_ptep_get handled unaligned addresses huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma). The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned. On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map or into a hole, dereference a VA not mapped into the kernel pgtables and cause kernel panic. Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68174", "url": "https://ubuntu.com/security/CVE-2026-68174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix union collision of module and refcnt for dynamic events In 'struct trace_event_call', the 'module' pointer and the 'refcnt' atomic variable share the same memory space in a union. For dynamic events, the union member is 'refcnt', which acts as an active reference counter. When a dynamic event (such as kprobe, uprobe, fprobe, eprobe, or wprobe) has a non-zero reference count (e.g. due to active event triggers or perf attachments), its 'call->module' evaluates to a small non-zero integer instead of NULL. When filtering or setting events for a specific module (e.g., writing ':mod:' to 'set_event'), the code in '__ftrace_set_clr_event_nolock()' and 'update_event_fields()' reads 'call->module' directly without checking whether the event is dynamic. This causes the kernel to treat the small integer (refcnt) as a 'struct module' pointer, leading to a NULL/invalid pointer dereference (Oops) when dereferencing the module name. Fix this by ensuring that the 'TRACE_EVENT_FL_DYNAMIC' flag is checked before treating 'call->module' as a valid pointer in these code paths.", "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-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-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-68434", "url": "https://ubuntu.com/security/CVE-2026-68434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms Commit b1b4efea05a5 (\"serial: 8250_mid: Disable DMA for selected platforms\") replaced the dnv_board setup and exit callbacks with PTR_IF(false, ...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. Fix this by adding the missing NULL checks before calling the setup and exit callbacks.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17: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-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-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16: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-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-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-68198", "url": "https://ubuntu.com/security/CVE-2026-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix use-after-free in aggr_reset_state() The aggr_reset_state() function uses timer_delete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggr_module_destroy(). If the timer callback (aggr_timeout) is executing when aggr_reset_state() is called, the callback will continue to access aggr_conn fields like rx_tid[] and stat[] which may be freed immediately after by kfree(aggr_info->aggr_conn) in aggr_module_destroy(). Additionally, the timer callback can re-arm itself via mod_timer() while aggr_reset_state() is running, creating a more complex race condition. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "high", "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-68200", "url": "https://ubuntu.com/security/CVE-2026-68200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: don't re-enter an instance callback that is still running The userspace-driven timer (utimer) TRIGGER ioctl calls snd_timer_interrupt() directly with no serialization, so two threads triggering the same utimer can run snd_timer_interrupt() on one snd_timer concurrently. snd_timer_process_callbacks() drops timer->lock around each instance callback and marks the in-flight callback with the single SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that bit to drain an in-flight callback before freeing the instance. The bit cannot represent two concurrent callbacks: when a second interrupt re-queues an instance whose callback is still running, both run at once, the first to finish clears the bit, and the close-path drain then frees the instance (and its callback_data) while the other callback is still live - a use-after-free reachable by any user able to open /dev/snd/timer, both via a user timer instance and via a sequencer queue timer bound to the utimer. snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so a concurrent interrupt already observes it under the lock. Skip re-queuing an instance (and its slaves) to the ack/sack list while its callback is in flight; the accumulated pticks are delivered on the next tick, so no event is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68201", "url": "https://ubuntu.com/security/CVE-2026-68201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: drain a slave's callback before its master detaches it snd_timer_close_locked() drains the closing instance's own in-flight callback (IFLG_CALLBACK) before freeing it, but not its slaves'. When a master instance is closed, remove_slave_links() clears each slave's ->timer; the slave's own close then reads timer == NULL and takes the branch that skips the drain entirely (snd_timer_stop_slave() also no-ops on a NULL timer). So a slave whose callback is still running when the master is closed is freed underneath the live callback, leading to use-after-free. Drain the slaves too before remove_slave_links() severs them. snd_timer_stop() has already taken this instance off the active list, so no new slave callback can be queued. Take the slaves off the ack list so a pending one can't fire either, then wait for any that is already in flight.", "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-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-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-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-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-68211", "url": "https://ubuntu.com/security/CVE-2026-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32-dcmipp: 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. dcmipp_bytecap_start_streaming() returned -EINVAL when the source subdevice could not be resolved from the media graph, before pm_runtime_resume_and_get() and media_pipeline_start() had been called. The remaining error paths already converge on the err_buffer_done label, which calls dcmipp_bytecap_all_buffers_done(..., VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate err_pm_put / err_media_pipeline_stop 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": "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-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-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-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-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-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-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-68230", "url": "https://ubuntu.com/security/CVE-2026-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: amlogic-c3: Add validations for ae and awb config Avoid invalid memory access if the zones_num is bigger than zone_weight. This patch fixes the following smatch errors: drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max", "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-68232", "url": "https://ubuntu.com/security/CVE-2026-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path.", "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-68233", "url": "https://ubuntu.com/security/CVE-2026-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Shut down BO cache timer before teardown The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20: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-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-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-68238", "url": "https://ubuntu.com/security/CVE-2026-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Release VFCT ACPI table reference amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68239", "url": "https://ubuntu.com/security/CVE-2026-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Account for NULL and handle pages in ttm_pool_backup Pages in ttm_pool_backup can be NULL or backup handles (ttm_backup_page_ptr_is_handle()), neither of which can be passed to set_pages_array_wb() or freed. Add a dedicated WB pass before the dma/purge loop that walks allocations using the same i += num_pages stride, skipping NULL and handle entries, and calls set_pages_array_wb() once per contiguous run of real pages. Apply the same NULL/handle guard to the dma/purge loop. Fixes the following oops: Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI RIP: 0010:__cpa_process_fault+0xf8/0x770 RSP: 0018:ffffc90000a87718 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34 RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0 R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000 R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0 FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0 PKRU: 55555554 Call Trace: __change_page_attr_set_clr+0x989/0xe90 ? __purge_vmap_area_lazy+0x6c/0x3a0 ? _vm_unmap_aliases+0x250/0x2a0 set_pages_array_wb+0x7f/0x120 ttm_pool_backup+0x4c9/0x5b0 [ttm] ? dma_resv_wait_timeout+0x3b/0xf0 ttm_tt_backup+0x32/0x60 [ttm] ttm_bo_shrink+0x66/0x110 [ttm] xe_bo_shrink_purge+0x12b/0x1b0 [xe] xe_bo_shrink+0xbb/0x270 [xe] __xe_shrinker_walk+0xf7/0x160 [xe] xe_shrinker_walk+0x9d/0xc0 [xe] xe_shrinker_scan+0x11f/0x210 [xe] do_shrink_slab+0x13b/0x270 shrink_slab+0xf1/0x400 shrink_node+0x352/0x8a0 balance_pgdat+0x32c/0x700 kswapd+0x205/0x2f0 ? __pfx_autoremove_wake_function+0x10/0x10 ? __pfx_kswapd+0x10/0x10 kthread+0xd1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1b1/0x200 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68241", "url": "https://ubuntu.com/security/CVE-2026-68241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/mst: limit DP MST ESI service loop The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto. (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)", "cve_priority": "medium", "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-68245", "url": "https://ubuntu.com/security/CVE-2026-68245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only valid while the lock is still being held. Once xa_unlock_irqrestore is called and returned, the pointer is no longer under lock and is subject to modification. Since, the caller still dereferences vm->task_info in amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a use after unlock problem. Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid() through removing the amdgpu_vm_get_vm_from_pasid() function from amdgpu_vm.c and making the relevant code inline to hold the lock while it is still in use. (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)", "cve_priority": "high", "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-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-68252", "url": "https://ubuntu.com/security/CVE-2026-68252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68253", "url": "https://ubuntu.com/security/CVE-2026-68253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)", "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-68257", "url": "https://ubuntu.com/security/CVE-2026-68257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix 32-bit overflow in CWSR total size calculation total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68258", "url": "https://ubuntu.com/security/CVE-2026-68258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on CRIU restore queue type and mqd size We weren't checking whether the values provided in the private data in kfd CRIU restore were within bounds. For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it. For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations. (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)", "cve_priority": "low", "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-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-68266", "url": "https://ubuntu.com/security/CVE-2026-68266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68268", "url": "https://ubuntu.com/security/CVE-2026-68268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Return error on non-migratable faults requiring devmem Non-migratable faults that require devmem incorrectly jump to the 'out' label, which squashes the error code intended to be returned to the upper layers. Fix this by returning -EACCES instead. (cherry picked from commit c4508edb2c723de93717272488ea65b165637eac)", "cve_priority": "medium", "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-68270", "url": "https://ubuntu.com/security/CVE-2026-68270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Avoid possible truncation with calculating visible size Calculating the visible size of the system framebuffer can result in truncation of the result. The calculation uses 32-bit arithmetics, which can overflow if the values for height and stride are large. Fix the issue by multiplying with mul_u32_u32().", "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-68275", "url": "https://ubuntu.com/security/CVE-2026-68275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks up the bo_va for the buffer object in the caller's VM via amdgpu_vm_bo_find(), but uses the returned pointer without checking it. amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM, which is the normal case for a BO that has never been mapped. The result is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which expands to list_for_each_entry(mapping, &(bo_va)->valids, list) and dereferences bo_va, causing a NULL pointer dereference. This is reachable by any process able to issue the ioctl (render group) simply by requesting mapping info for an unmapped BO. Return -ENOENT when no bo_va is found, jumping to out_exec so the drm_exec context and GEM object reference are released. (cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68276", "url": "https://ubuntu.com/security/CVE-2026-68276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx: fix cleaner shader IB buffer overflow The cleaner shader sysfs path allocates a 16-dword (64 byte) IB but incorrectly fills (align_mask + 1) dwords. On GFX rings align_mask is 0xff, so the loop wrote 256 dwords into a 64-byte buffer, causing a kernel page fault. The IB only needs to be a minimal NOP shell to schedule the job; the cleaner shader itself is emitted on the ring via emit_cleaner_shader(). Fill 16 dwords to match the allocation. v2: Use ib_size_dw variable (Lijo) (cherry picked from commit bf21af331ebf72d0935fd70c73192414a422c03a)", "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-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-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-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-68282", "url": "https://ubuntu.com/security/CVE-2026-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: analogix_dp: Add missing error check for platform_get_resource() Add missing error check for platform_get_resource() return value to prevent NULL pointer dereference when memory resource is not available.", "cve_priority": "medium", "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-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-68292", "url": "https://ubuntu.com/security/CVE-2026-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues.", "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-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-68296", "url": "https://ubuntu.com/security/CVE-2026-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM Before commit 00d066a4d4ed (\"netdev_features: convert NETIF_F_LLTX to dev->lltx\"), NETIF_F_LLTX was set unconditionally in both __gre_tunnel_init() and ip6gre_tnl_init_features() alongside GRE_FEATURES: dev->features |= GRE_FEATURES | NETIF_F_LLTX; When that commit converted NETIF_F_LLTX to the dev->lltx flag, it placed 'dev->lltx = true' after the SEQ/CSUM early returns instead of before them. This causes GRE/GRETAP/ip6gre tunnels with SEQ or CSUM+encap to lose lockless TX, reintroducing _xmit_lock acquisition around their ndo_start_xmit. Since GRE xmit re-enters the stack via ip_tunnel_xmit(), holding _xmit_lock risks ABBA deadlock with the underlay device. CPU0 CPU1 ---- ---- lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); Fix by moving dev->lltx = true before the early returns in both functions, restoring the original unconditional behavior.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64575", "url": "https://ubuntu.com/security/CVE-2026-64575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: fix double sock release on batch realloc bpf_iter_tcp_batch() releases the current batch via bpf_iter_tcp_put_batch(), which drops the socket refs and rewrites each slot with the socket cookie, then grows the batch. cur_sk/end_sk are kept for bpf_iter_tcp_resume(), but on realloc failure the function returns ERR_PTR() before resume runs, leaving cur_sk < end_sk over slots that now hold cookies rather than sock pointers. bpf_iter_tcp_seq_stop() then calls bpf_iter_tcp_put_batch() again and dereferences a cookie as a struct sock. Empty the batch on the failure path so stop() does not release it again. The sockets were already freed by the first bpf_iter_tcp_put_batch(), so nothing leaks, and a later read() rescans the bucket from the start instead of skipping it. The sibling GFP_NOWAIT failure path still holds real socket references and is left for stop() to release. BUG: KASAN: null-ptr-deref in __sock_gen_cookie Read of size 8 at addr 0000000000000059 by task exploit ... __sock_gen_cookie (net/core/sock_diag.c:28) bpf_iter_tcp_put_batch (net/ipv4/tcp_ipv4.c:2918) bpf_iter_tcp_seq_stop (net/ipv4/tcp_ipv4.c:3270) bpf_seq_read (kernel/bpf/bpf_iter.c:205) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 entry_SYSCALL_64_after_hwframe Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68298", "url": "https://ubuntu.com/security/CVE-2026-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create() Commit 9e9787414882 (\"drm/xe/userptr: replace xe_hmm with gpusvm\") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a \"simple\" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). (cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4)", "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-68448", "url": "https://ubuntu.com/security/CVE-2026-68448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: check access to copy_file_range source with src mounter creds Commit 5dae222a5ff0c (\"vfs: allow copy_file_range to copy across devices\") allowed filesystems that implement the copy_file_range() f_op to decide if they want to access cross-sb copy from/to the same fs type. The same commit added checks to verify same sb copy for filesystems that implement ->copy_file_range() and do not support cross-sb copy at the time, namely, to ceph, fuse and nfs. The two remaining fs which implement ->copy_file_range(), cifs and overlayfs started to support cross-sb copy from this time. While overlayfs does support cross-sb copy when the two underlying files are on the same base fs, the copy operation on the two real files from two different overalyfs filesystems is performed with the mounter creds of the destination overlayfs and the read permission access hook for the source file was called with the wrong creds. This could cause either deny of access to copy which would otherwise be allowed (e.g. with splice) or allow read access to file which would otherwise be denied. Fix the latter case by explicitly verifying read access to source file with the source overlayfs mounter creds. The former case remains a quirk of cross-sb overlayfs copy, but userspace could fall back to regular copy so no harm done.", "cve_priority": "low", "cve_public_date": "2026-08-12 01:17: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-68307", "url": "https://ubuntu.com/security/CVE-2026-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix crash in reset link replay During reset recovery, mt7925_vif_connect_iter() replays firmware state for links tracked in mvif->valid_links. After MLO link changes or MCU timeout recovery, the driver bitmap can temporarily contain a link whose mac80211 bss_conf has already gone away. This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching the crash where x1, the second argument, is NULL: pc : mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] lr : mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] x2 : ffffff80a77f6018 x1 : 0000000000000000 x0 : ffffff8099402080 Call trace: mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common] Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA reset replay is unchanged because the helper still returns &vif->bss_conf for the legacy link.", "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-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-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-68311", "url": "https://ubuntu.com/security/CVE-2026-68311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: guard link STA in decap offload mt7925_sta_set_decap_offload() iterates over the vif valid_links mask when updating decap offload state for an MLO station. The station may not have a link STA for every valid link of the vif, so mt792x_sta_to_link() can return NULL for a link that belongs to the vif but not to the station. The function currently dereferences mlink before checking whether the link WCID is ready. If mlink is NULL, setting or clearing MT_WCID_FLAG_HDR_TRANS dereferences a NULL pointer. Skip links without a station link before touching mlink->wcid.", "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-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-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-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-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-68321", "url": "https://ubuntu.com/security/CVE-2026-68321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix FDIR filter leak on remove Perfect FDIR filters can be added while the interface is down and are kept on the software list for later restore. unregister_netdev() only calls ndo_stop when the device is up, so txgbe_fdir_filter_exit() in txgbe_close() is skipped in that case and the filters are leaked on driver remove. Free the filter list from txgbe_remove() as well.", "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-68330", "url": "https://ubuntu.com/security/CVE-2026-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix DMA direction for NPU mailbox buffer airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE, but some callers expect the NPU to write response data back into the same buffer: - airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into the buffer, then the caller reads it via memcpy() - airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back npu_stats_addr field in the response On non-cache-coherent architectures like EN7581 (Cortex-A53 without hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op — it does not invalidate the CPU cache. If the NPU-written cache line is still present in the CPU cache when the caller reads the buffer, the CPU observes stale data instead of the NPU response. This is a timing-sensitive bug: small mailbox buffers (~24 bytes) typically fit in a single cache line and may survive in the cache until the caller reads them, producing silent data corruption rather than a crash. The bug is more likely to trigger when the caller reads the response immediately after dma_unmap_single() without intervening cache-evicting operations. Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures dma_unmap_single() invalidates the CPU cache on non-coherent systems. The mailbox buffers are small so there is no performance concern.", "cve_priority": "low", "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-68332", "url": "https://ubuntu.com/security/CVE-2026-68332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix potential use-after-free in airoha_ppe_deinit() airoha_ppe_deinit() replaces the NPU pointer with NULL via rcu_replace_pointer() but does not wait for existing RCU readers to exit before calling ppe_deinit() and airoha_npu_put(). This can cause a use-after-free if a reader in an RCU read-side critical section still holds a reference to the NPU when it is freed. The init path (airoha_ppe_init) already calls synchronize_rcu() after rcu_assign_pointer(), but the deinit path introduced in commit 6abcf751bc08 (\"net: airoha: Fix schedule while atomic in airoha_ppe_deinit()\") omitted the matching barrier when switching from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer(). Add synchronize_rcu() before ppe_deinit() to ensure all existing RCU readers have completed before the NPU resources are released.", "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-68334", "url": "https://ubuntu.com/security/CVE-2026-68334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix io_thread race in rxrpc_wake_up_io_thread() rxrpc_wake_up_io_thread() checks local->io_thread before waking it, but then reloads the pointer for wake_up_process(). local->io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so the second load can see NULL even if the first load did not. Take a READ_ONCE() snapshot and use it for both the NULL check and the wake_up_process() call, as rxrpc_encap_rcv() already does.", "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-68341", "url": "https://ubuntu.com/security/CVE-2026-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix use after free in unlock_ovpn() unlock_ovpn() iterates over the release_list using llist_for_each_entry() and drops the peer reference inside the loop body via ovpn_peer_put(). If this drops the last reference, the peer is eventually freed. However, llist_for_each_entry() reads peer->release_entry.next in the loop advance expression, which runs after the body. By that time the peer may have already been freed, resulting in a use after free when advancing to the next list entry. Fix this by using llist_for_each_entry_safe(), which caches the next pointer before executing the loop body.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68342", "url": "https://ubuntu.com/security/CVE-2026-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: avoid putting unrelated P2P peer on socket release ovpn_peer_release_p2p() is called when an OVPN UDP socket is being destroyed. It checks the currently published P2P peer and releases it only if that peer still uses the socket being destroyed. A peer replacement can publish a new peer before the old UDP socket is destroyed. When the old socket destruction path runs afterwards, ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the new peer uses a different socket, the function takes the socket mismatch branch. That branch still calls ovpn_peer_put(peer). At this point, however, peer is the currently published replacement peer, not the peer associated with the socket being destroyed. Dropping its reference can free it while ovpn->peer still points to it, leading to later use-after-free accesses from the peer and socket cleanup paths. KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer object. In the reproducer, the object is allocated from ovpn_peer_new() via ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU callback processing. Observed access sites include ovpn_peer_remove(), ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn(). Fix this by returning from the socket mismatch branch without putting the peer.", "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-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-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-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-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-68356", "url": "https://ubuntu.com/security/CVE-2026-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: airoha: Prevent division by zero when clock frequency is zero clk_get_rate() can return 0 when the clock provider is not properly configured or the clock is unmanaged. The driver uses wdt_freq as a divisor directly in airoha_wdt_probe() to compute max_timeout and in airoha_wdt_get_timeleft() to compute the remaining time, which results in a division by zero. Add a check for wdt_freq == 0 in probe and return -EINVAL with dev_err_probe() to prevent the division by zero and provide a diagnostic message.", "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-68358", "url": "https://ubuntu.com/security/CVE-2026-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-kraken3) 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-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-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-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-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-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-68374", "url": "https://ubuntu.com/security/CVE-2026-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: sysfs: add lock to bos_descriptors_read() Add a lock to the function bos_descriptors_read(). This function accesses udev->bos, which could be simultaneously freed in usb_reset_and_verify_device(), a function that is commonly called in drivers all over the kernel.", "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-68378", "url": "https://ubuntu.com/security/CVE-2026-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions: - A pin is registered with two or more dpll devices (dpll_A, dpll_B) - The pin has ref_sync pairs with other pins - During unregistration of dpll_A's pins, a ref_sync partner pin is unregistered first, removing it from dpll_A->pin_refs - But since the partner pin is still registered with dpll_B, its dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT run and the partner stays in the pin's ref_sync_pins xarray - When the pin itself is then unregistered from dpll_A, the delete notification calls dpll_msg_add_pin_ref_sync() which finds the partner in ref_sync_pins, passes dpll_pin_available() (partner is still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A, partner) returns NULL because partner was already removed from dpll_A->pin_refs - The NULL priv pointer is passed to the driver's ref_sync_get callback, which dereferences it BUG: kernel NULL pointer dereference, address: 0000000000000034 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x] Call Trace: dpll_msg_add_pin_ref_sync+0xb8/0x200 dpll_cmd_pin_get_one+0x3b6/0x4b0 dpll_pin_event_send+0x72/0x140 __dpll_pin_unregister+0x5a/0x2b0 dpll_pin_unregister+0x49/0x70 Fix this by skipping ref_sync pins whose priv pointer cannot be resolved for the current dpll device.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68379", "url": "https://ubuntu.com/security/CVE-2026-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix TIME_WAIT socket reference leak on PSP policy failure Release the TIME_WAIT socket reference and jump to discard_it upon PSP policy failure in both IPv4 and IPv6 receive paths. This prevents a memory leak of tcp_tw_bucket structures.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68380", "url": "https://ubuntu.com/security/CVE-2026-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix use-after-free of mm_struct in job scheduler amdxdna_cmd_submit() stores current->mm in job->mm without holding any reference. aie2_sched_job_run() later access job->mm from the DRM scheduler worker thread. With only a raw pointer and no structural reference, the mm_struct can be freed before the scheduler runs the job. Fix this by calling mmgrab() to hold a structural mm_count reference for the lifetime of the job, paired with mmdrop() in every cleanup path.", "cve_priority": "high", "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-68384", "url": "https://ubuntu.com/security/CVE-2026-68384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits. - Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it. While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one. (cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68385", "url": "https://ubuntu.com/security/CVE-2026-68385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/checksum: Fix csum_partial() without vector facility Currently csum_partial() calls csum_copy() with copy=false and dst=NULL. On machines without the vector facility, csum_copy() falls back to cksm(dst, ...), causing the checksum to be calculated from address zero instead of the source buffer. The VX implementation already checksums data loaded from src. Make the fallback do the same by passing src to cksm().", "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-68387", "url": "https://ubuntu.com/security/CVE-2026-68387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: add locking for raw flags bitfield With commit 890e5198a6e5 (\"can: raw: use bitfields to store flags in struct raw_sock\") the formerly separate integer values have been integrated into a single bitfield. This led to a read-modify-write operation when changing a flag in raw_setsockopt() which now needs a locking to prevent concurrent access. Instead of adding a lock/unlock hell in each of the flag manipulations this patch introduces a wrapper for a new raw_setsockopt_locked() function analogue to the isotp_setsockopt[_locked]() approach in net/can/isotp.c [mkl: use Closes tag instead of Link]", "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-68393", "url": "https://ubuntu.com/security/CVE-2026-68393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: extend conn_hash lookup critical sections Using RCU-protected pointers outside the critical sections without refcount is incorrect and may result to UAF. Extend critical section to cover both hci_conn_hash lookup and use of the returned conn. Add surrounding rcu_read_lock() also when return value is not used, in preparation for RCU lockdep requirement to hci_lookup_le_connect(). This avoids concurrent deletion of the conn before we are done dereferencing it. Also, make sure to hold hdev->lock when accessing hdev->accept_list.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68394", "url": "https://ubuntu.com/security/CVE-2026-68394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update MGMT_OP_LOAD_CONN_PARAM queues conn_update_sync() when a single parameter update changes an existing LE central connection. The queued work currently stores a borrowed hci_conn_params entry from hdev->le_conn_params. A later LOAD_CONN_PARAM request can clear disabled parameters and free that entry before hci_cmd_sync_work() runs the queued callback. Do not keep the borrowed hci_conn_params pointer in queued work. Queue the hci_conn instead and hold a reference until the queued callback completes. When the work runs, revalidate that the connection is still present, look up the current hci_conn_params entry, and cancel the update if userspace removed that entry while the work was pending. Copy the interval values from the current params entry under hdev->lock, then drop the lock and keep using hci_le_conn_update_sync() to issue the update. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in conn_update_sync+0x2a/0xf0 [bluetooth] Read of size 1 at addr ffff88810c697126 by task kworker/u17:0/377 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 kasan_report+0xe0/0x110 conn_update_sync+0x2a/0xf0 [bluetooth] hci_cmd_sync_work+0x187/0x210 [bluetooth] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 Allocated by task 466: hci_conn_params_add+0xa6/0x240 [bluetooth] load_conn_param+0x4e1/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] Freed by task 474: kfree+0x313/0x590 hci_conn_params_clear_disabled+0x9b/0xc0 [bluetooth] load_conn_param+0x4bf/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth]", "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-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-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-68400", "url": "https://ubuntu.com/security/CVE-2026-68400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint memory access array and to comply with the FF-A spec instead of defaulting to `sizeof(struct ffa_mem_region)`. This requires moving `ffa_mem_region_additional_setup()` earlier in the setup flow. Also, add sanity checks to ensure the calculated descriptor offsets do not exceed `max_fragsize`.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68401", "url": "https://ubuntu.com/security/CVE-2026-68401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() Sashiko (locally) reports multiple out-of-bound issues in ffa_setup_and_transmit: 1) Writing ep_mem_access->reserved can write out of bounds for FFA versions < 1.2 as ffa_emad_size_get() returns 16 bytes in that case while reserved has an offset of 24. Instead of zeroing fields, memset the struct to zero first based on the FFA version. 2) Make sure there is enough size to write constituents. While at it, convert the only sizeof() in the driver that uses a type instead of variable.", "cve_priority": "high", "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-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-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-68409", "url": "https://ubuntu.com/security/CVE-2026-68409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: defer link RX stats percpu free to RCU sta_remove_link() frees a removed MLO link's RX stats percpu buffer right away, but defers only the link container to RCU: \tsta_info_free_link(&alloc->info); \tkfree_rcu(alloc, rcu_head); The RX fast path reads link_sta under rcu_read_lock and writes the percpu stats. A reader that resolved link_sta before the removal keeps the pointer. The container stays alive from the kfree_rcu, so the read still works. But the percpu block it points to is already freed. This needs uses_rss. That is when pcpu_rx_stats exists. The full STA teardown frees the deflink stats only after synchronize_net(). The link removal path had no such barrier. The race is hard to win in practice, but the free should still wait for RCU. Free the link together with its data from a single RCU callback, so the percpu block is reclaimed only after readers drain.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20: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-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-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-68412", "url": "https://ubuntu.com/security/CVE-2026-68412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan() If the test against IEEE80211_MAX_SSID_LEN fails, then 'creq' leaks. Use the existing error handling path to fix it.", "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-64566", "url": "https://ubuntu.com/security/CVE-2026-64566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags() When iptfs_skb_add_frags() copies frag references from the source frag walk into a new SKB, it increments the page reference count via __skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the destination SKB's skb_shinfo->flags. If the source SKB carries shared frags (e.g. from a page-pool backed receive path), the new inner SKB will appear to ESP as having privately owned frags. A subsequent esp_input() call for a nested transport-mode SA then takes the no-COW fast path and decrypts in place, writing over pages that are still referenced by the outer IPTFS SKB. This causes kernel-visible memory corruption and can trigger a panic. All other frag-transfer helpers in the kernel (skb_try_coalesce, skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this convention by setting the flag inside the loop immediately after __skb_frag_ref() and nr_frags++, so every exit path that attaches a frag unconditionally propagates SKBFL_SHARED_FRAG.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68415", "url": "https://ubuntu.com/security/CVE-2026-68415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear mode callbacks after failed mode setup xfrm_state_gc_task can run long after a failed IPTFS state setup. In the reproduced case, __xfrm_init_state() cached x->mode_cbs, IPTFS setup returned -ENOMEM before publishing mode_data, and the temporary module reference from xfrm_get_mode_cbs() was dropped immediately. The dead state then kept x->mode_cbs until deferred GC ran after xfrm_iptfs had been unloaded. Clear x->mode_cbs when mode init or clone fails before publishing mode_data. Those states never installed mode-specific state or the long-term IPTFS module pin, so deferred GC has nothing mode-specific to destroy and must not retain a callback table pointer past the temporary lookup reference. The buggy scenario involves two paths, with each column showing the order within that path: failed setup path: 1. cache x->mode_cbs 2. mode setup fails before mode_data 3. drop the temporary module ref 4. dead state keeps x->mode_cbs cached GC/unload path: 1. xfrm_state_put() queues GC work 2. xfrm_iptfs unloads later 3. xfrm_state_gc_task runs 4. GC dereferences stale x->mode_cbs This also covers the failed clone path where clone_state() returns before publishing mode_data. Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y failslab_stacktrace_filter matched xfrm_iptfs frames ack_error=-12 FAULT_INJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrm_state_gc_task RIP: xfrm_state_gc_task+0x142/0x650 Modules linked in: esp4_offload xfrm_user [last unloaded: xfrm_iptfs] Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68418", "url": "https://ubuntu.com/security/CVE-2026-68418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent user-triggered null deref on QP create Previously, the user QP creation path would only attempt to populate iwqp->iwpbl if the user-provided req.user_wqe_bufs field was non-zero. The problem is that iwqp->iwpbl is unconditionally dereferenced later on in irdma_setup_virt_qp. While there was a check for iwqp->iwpbl != NULL, this check would only occur if req.user_wqe_bufs was non-zero. The end result is that a user could send a zero user_wqe_bufs value and trigger a null ptr deref. Fix this by unconditionally calling irdma_get_pbl and bailing if it fails, similar to the CQ and SRQ paths.", "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-68420", "url": "https://ubuntu.com/security/CVE-2026-68420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: reject optional IPTFS templates in outbound policies syzbot reported a stack-out-of-bounds read in xfrm_state_find() which flows from xfrm_tmpl_resolve_one(). Commit 3d776e31c841 (\"xfrm: Reject optional tunnel/BEET mode templates in outbound policies\") disallowed optional tunnel and BEET in outbound policies to prevent this. Later when IPTFS added, it was not covered by that fix and can still trigger the out-of-bounds read; Extend the check to disallow optional IPTFS in outbound policies as well. IPTFS should be identical to tunnel mode. IN and FWD policies are not affected: xfrm_tmpl_resolve_one() is only reachable via the outbound path. Reproducer, before: ip link add dummy0 type dummy ip link set dummy0 up ip addr add 10.1.1.1/24 dev dummy0 ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 mode transport ping -W 1 -c 1 10.1.1.2 PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data. [ 64.168420] ================================================================== [ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844 [ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full) [ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 64.169977] Call Trace: [ 64.169977] [ 64.169977] dump_stack_lvl+0x47/0x70 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] print_report+0x152/0x4b0 [ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0 [ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20 [ 64.169977] ? __virt_addr_valid+0x21b/0x230 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] kasan_report+0xa8/0xd0 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm_dst_hash+0x24/0xc0 [ 64.169977] xfrm_state_find+0xa2d/0x2f90 [ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570 [ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10 [ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 64.169977] ? kernel_text_address+0x5b/0x80 [ 64.169977] ? __kernel_text_address+0xe/0x30 [ 64.169977] ? unwind_get_return_address+0x5e/0x90 [ 64.169977] ? arch_stack_walk+0x8c/0xe0 [ 64.169977] xfrm_tmpl_resolve+0x130/0x200 [ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10 [ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110 [ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10 [ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310 [ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80 [ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10 [ 64.169977] ? ip_route_output_key_hash+0xc6/0x110 [ 64.169977] ? kasan_save_track+0x10/0x30 [ 64.169977] xfrm_lookup_route+0x18/0xe0 [ 64.169977] ip4_datagram_release_cb+0x4c9/0x530 [ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10 [ 64.169977] ? do_raw_spin_lock+0x71/0xc0 [ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 64.169977] release_sock+0xb0/0x170 [ 64.169977] udp_connect+0x43/0x50 [ 64.169977] __sys_connect+0xa6/0x100 [ 64.169977] ? alloc_fd+0x2e9/0x300 [ 64.169977] ? __pfx___sys_connect+0x10/0x10 [ 64.169977] ? preempt_latency ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68421", "url": "https://ubuntu.com/security/CVE-2026-68421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx() put_prev_task_scx() warns when a runnable task drops to a lower sched_class without SCX_OPS_ENQ_LAST, on the assumption that balance_one() would have kept it running. Core scheduling breaks that: a forced-idle SMT sibling reschedules through the core_pick fast path in pick_next_task(), which skips pick_task_scx() and thus balance_one(), so a runnable task can drop to idle with ENQ_LAST unset. Gate the warning on sched_cpu_cookie_match(): a cookie mismatch means core scheduling forced the idle, while a match (or core scheduling off) still catches a genuine missing-ENQ_LAST drop.", "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-68426", "url": "https://ubuntu.com/security/CVE-2026-68426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix stale skb->prev after async crypto steals a GSO segment skb_gso_segment() leaves the segment list head with ->prev pointing at the last segment, an invariant validate_xmit_skb_list() relies on when it sets its tail pointer (tail = skb->prev). When validate_xmit_xfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validate_xmit_skb_list() later does tail->next = skb, writing through that stale pointer -- a use-after-free. Repoint skb->prev at the last retained segment before returning.", "cve_priority": "critical", "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-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-2023-20585", "url": "https://ubuntu.com/security/CVE-2023-20585", "cve_description": "Insufficient checks of the RMP on host buffer access in IOMMU may allow an attacker with privileges and a compromised hypervisor to trigger an out of bounds condition without RMP checks, resulting in a potential loss of confidential guest integrity.", "cve_priority": "low", "cve_public_date": "2026-04-16 19:16:00 UTC" }, { "cve": "CVE-2026-68364", "url": "https://ubuntu.com/security/CVE-2026-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix ISM dc_lock deadlock during suspend [Why] System hang observed during suspend/resume while video is playing. amdgpu_dm_ism_disable() is called under dc_lock and waits for ISM delayed work via disable_delayed_work_sync(). The work handlers themselves take dc_lock, producing an ABBA deadlock when a worker is in flight at suspend time. [How] Split the disable path into two phases with opposite locking contracts: 1. amdgpu_dm_ism_disable() -- quiesces workers, must NOT hold dc_lock. 2. amdgpu_dm_ism_force_full_power() (new) -- drives the ISM FSM back to FULL_POWER_RUNNING, must hold dc_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72064", "url": "https://ubuntu.com/security/CVE-2026-72064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Sync page pool RX frags for CPU MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack.", "cve_priority": "medium", "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-72098", "url": "https://ubuntu.com/security/CVE-2026-72098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: fix buffer overflow in FEC calculation There's a buffer overflow in dm-verity-fec: if (neras && *neras <= v->fec->roots) \tfio->erasures[(*neras)++] = i; This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72248", "url": "https://ubuntu.com/security/CVE-2026-72248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: support IPIP tunnel with direct xmit The combination of IPIP tunnel with direct xmit, eg. bridge device, breaks because no dst_entry is provided to check the skb headroom and to set the iph->frag_off field. This leads to invalid dst usage and can trigger a crash in the tunnel transmit path. Fix this by moving dst_cache and dst_cookie out of the runtime union so that they can be shared by neighbour, xfrm, and direct tunnel flows. For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve route state in these shared fields and release it through the common dst release path. Since dst_entry is now available to the three supported xmit modes and dst_release() already deals with NULL dst, remove the xmit type check in nft_flow_dst_release(). Moreover, skip the check if the dst entry is NULL in nf_flow_dst_check() which is now the case for the direct xmit case. Based on patch from Rein Wei .", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72249", "url": "https://ubuntu.com/security/CVE-2026-72249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: use dst in this direction when pushing IPIP header When pushing the IPIP header, the route of the other direction is used to calculate the headroom, use the route in this direction. Accessing the other tuple to set the IP source and destination is fine because this tuple does not provide such information to avoid storing redundant information. However, this tuple already provides the dst for this direction, this went unnoticed because this bug affects headroom and iph->frag_off only at this stage.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72287", "url": "https://ubuntu.com/security/CVE-2026-72287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the \"normal\" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a \"late\" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72329", "url": "https://ubuntu.com/security/CVE-2026-72329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/liquidio: drop cached VF pci_dev LUT The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST. Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72355", "url": "https://ubuntu.com/security/CVE-2026-72355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix barriering when walking subrequest list Fix the barriering used when walking the subrequest list in retry as there's a possibility of seeing a subreq that's just been added by the application thread.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72412", "url": "https://ubuntu.com/security/CVE-2026-72412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/mm: Fix handling of _PAGE_UNUSED pte bit The _PAGE_UNUSED softbit should not really be lying around. Its sole purpose is to signal to try_to_unmap_one() and try_to_migrate_one() that the page can be discarded instead of being moved / swapped. KVM has no way to know why a page is being unmapped, so it sets the bit on userspace ptes corresponding to unused guest pages every time they get unmapped. KVM has no reasonable way to clear the bit once the page is in use again. While set_ptes() checks and clears the bit, other paths that set new ptes did not. This led to used pages being thrown out as if they were unused, causing guest corruption. Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in set_pte(), i.e. whenever a present pte is getting set. The check in set_ptes() is then redundant and can be removed. Also fix gmap_helper_try_set_pte_unused() to only set the bit if the pte is present; the _PAGE_UNUSED bit is only defined for present ptes and thus should not be set for non-present ptes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72417", "url": "https://ubuntu.com/security/CVE-2026-72417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto() Add sanity check for iph->ihl field in nf_flow_ip4_tunnel_proto() before using it to compute the header size, avoiding out-of-bounds access with malformed IP headers. While at it, use iph->protocol instead of the hardcoded IPPROTO_IPIP constant when setting ctx->tun.proto and reference ctx->tun.hdr_size when updating ctx->offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72442", "url": "https://ubuntu.com/security/CVE-2026-72442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: fix and simplify IP6IP6 tunnel handling Fix nf_flow_ip6_tunnel_proto() to use pskb_may_pull() instead of skb_header_pointer() to ensure the outer IPv6 header is in the skb headroom, which is required for subsequent packet processing. Move ctx->offset update inside the IPPROTO_IPV6 conditional block since it should only be adjusted when an IP6IP6 tunnel is actually detected. Simplify the rx path by removing ipv6_skip_exthdr() and checking ip6h->nexthdr directly, as the flowtable fast path only handles simple IP6IP6 encapsulation without extension headers. Drop the tunnel encapsulation limit destination option support from the tx path to match, since the rx path no longer handles extension headers. Remove the encap_limit parameter from nf_flow_offload_ipv6_forward(), nf_flow_tunnel_ip6ip6_push() and nf_flow_tunnel_v6_push(), along with the ipv6_tel_txoption struct and related headroom/MTU adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72463", "url": "https://ubuntu.com/security/CVE-2026-72463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix dev use-after-free in xfrm async resumption xfrm async resumption hold skb->dev refcnt until after transport_finish. However, xfrm_rcv_cb may modify skb->dev to tunnel dev without taking device reference, such as vti_rcv_cb. The subsequent async resumption will decrement the tunnel device's reference count, which lead to uaf of tunnel dev and refcnt leak of orig dev as below: unregister_netdevice: waiting for vti1 to become free. Usage count = -2 Stash the original skb->dev to fix refcnt imbalance. The new skb->dev set by xfrm_rcv_cb can race with device teardown. Extend rcu protection over xfrm_rcv_cb and transport_finish to prevent races.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72477", "url": "https://ubuntu.com/security/CVE-2026-72477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: call _ntfs_bad_inode() when failing to rename It is safe to call _ntfs_bad_inode on live inodes since: commit 519b078998ce (\"fs/ntfs3: Exclude call make_bad_inode for live nodes.\") The WARN_ON was added when it wasn't safe by: commit d99208b91933 (\"fs/ntfs3: cancle set bad inode after removing name fails\") Replace the WARN_ON with a call to _ntfs_bad_inode() to prevent further operations on the inconsistent inode.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72493", "url": "https://ubuntu.com/security/CVE-2026-72493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: serialize netif_running() check in enqueue_to_backlog() Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup(). The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit). Commit e9e4dd3267d0 (\"net: do not process device backlog during unregistration\") introduced a lockless netif_running() check in enqueue_to_backlog() to prevent queuing packets to an unregistering device. However, this creates a TOCTOU race window. A lockless transmitter (like veth_xmit) can pass the check before dev_close() clears IFF_UP. If the transmitter is then delayed, flush_all_backlogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed. Fix this by moving the netif_running() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netif_running() after the flush/close completes (so it gets dropped).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72494", "url": "https://ubuntu.com/security/CVE-2026-72494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Replace waitqueue and flag with completion The driver previously used a waitqueue along with an explicit request_done flag, but without proper barriers around request_done. An earlier patch by Gui-Dong Han attempted to fix this by adding the missing memory barriers. Rather than adding the barriers, this patch replaces the waitqueue+flag with a completion, which is designed for this exact purpose.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72496", "url": "https://ubuntu.com/security/CVE-2026-72496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Proper rollback if the ioremap fails bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74269", "url": "https://ubuntu.com/security/CVE-2026-74269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt: fix head underflow on XDP head-grow The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free. The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with this commit applied causes the test to run successfully to completion. The other rx_skb_func implementations don't have this issue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74350", "url": "https://ubuntu.com/security/CVE-2026-74350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate fast symlink target during inode read ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment. A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer. Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated. This keeps malformed fast symlinks from reaching the read path. Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x19f/0x330 (?:?) kasan_report+0xe0/0x110 (?:?) kasan_check_range+0x105/0x1b0 (?:?) __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72495", "url": "https://ubuntu.com/security/CVE-2026-72495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid repeated requests to allocate WC pages Applications can request multiple WC pages for the same ucontext. As of now, only 1 WC page per ucontext is supported. Add a lock to avoid concurrent access and a check to fail repeated requests. Also, if the mmap entry insert fails for the WC, free the Doorbell page index mapped for the WC page.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72501", "url": "https://ubuntu.com/security/CVE-2026-72501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Initialize dpi variable to zero dpi is initialized only for BNXT_RE_ALLOC_WC_PAGE, but copied for all the cases. So initialize the dpi to 0.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72278", "url": "https://ubuntu.com/security/CVE-2026-72278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Re-translate VNCR before injecting abort KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor updates and MMU faults.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68083", "url": "https://ubuntu.com/security/CVE-2026-68083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix path resolution in ksmbd_vfs_kern_path_create The SMB2 open lookup is rooted at the share with LOOKUP_BENEATH, but the create/mkdir/hardlink sink is not: ksmbd_vfs_kern_path_create() builds an absolute path with convert_to_unix_name() and resolves it from AT_FDCWD via start_creating_path(), so a \"..\" component is walked from the real filesystem root and escapes the export. An authenticated client races a missing path component so the rooted open lookup returns -ENOENT (taking the create branch) while the same component is present (a directory) when the create walk runs; the create then resolves \"..\" out of the share. Root the create walk at the share like the lookup and rename paths already are: resolve the parent with vfs_path_parent_lookup(..., LOOKUP_BENEATH, &share_conf->vfs_path) and create the final component with start_creating_noperm(). convert_to_unix_name() then has no callers and is removed.", "cve_priority": "high", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-68457", "url": "https://ubuntu.com/security/CVE-2026-68457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use opener credentials for FSCTL mutations SET_SPARSE, SET_ZERO_DATA and SET_COMPRESSION operate on an open SMB handle but call VFS xattr, fallocate or fileattr helpers with the current ksmbd worker credentials. Those helpers can revalidate inode permissions, ownership and LSM policy independently of the SMB handle access mask. Run each operation with the credentials captured in the target file when the handle was opened. Keep credential handling local to these single-file FSCTLs rather than applying session credentials to the complete IOCTL handler, which also contains handle-less and multi-handle operations.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72041", "url": "https://ubuntu.com/security/CVE-2026-72041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: use sk_msg_free_partial to fix partial send sk_msg_free_partial() ensures consistency of the skmsg at every iteration, without having to manually handle uncharges and offsets. This simplifies the code, and fixes some bugs in skmsg accounting when we don't send the full contents.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72046", "url": "https://ubuntu.com/security/CVE-2026-72046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing.", "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-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21: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-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72137", "url": "https://ubuntu.com/security/CVE-2026-72137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: nat_keepalive: avoid double free on send error nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6 send helper reports an error. That cleanup is only correct before the skb is handed to the output path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the networking stack may already have consumed the skb before returning an error, so freeing it again is unsafe. Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4() and nat_keepalive_send_ipv6(), where the caller still owns the skb, and keep nat_keepalive_send() responsible only for family dispatch and the unsupported-family cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72139", "url": "https://ubuntu.com/security/CVE-2026-72139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: defer md5sig_info kfree past RCU grace period in tcp_connect The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: \tif (needs_md5) { \t\ttcp_ao_destroy_sock(sk, false); \t} else if (needs_ao) { \t\ttcp_clear_md5_list(sk); \t\tkfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); \t} Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with tcp-diag]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72191", "url": "https://ubuntu.com/security/CVE-2026-72191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: validate split-point offset in indx_insert_into_buffer indx_insert_into_buffer() computes used = used1 - to_copy - sp_size; memmove(de_t, Add2Ptr(sp, sp_size), used - le32_to_cpu(hdr1->de_off)); where sp and sp_size come from hdr_find_split(). hdr_find_split() walks entries by le16_to_cpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFS_DE). index_hdr_check(), the on-load gatekeeper, only validates header-level fields (used, total, de_off) and does not walk per-entry sizes. A crafted NTFS image whose leaf INDEX_HDR reports used == total but contains one interior NTFS_DE with size = 0xFFF0 therefore passes validation, descends to indx_insert_into_buffer() through the ntfs_create() -> indx_insert_entry() path, and makes hdr_find_split() return an sp whose sp_size (0xFFF0) greatly exceeds the remaining bytes in the buffer. The u32 subtraction underflows and the memmove count becomes a near-4-GiB value, producing an out-of-bounds kernel write that corrupts adjacent allocations and panics the kernel. Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a single 'touch' inside the mounted directory; crash site resolves to fs/ntfs3/index.c at the memmove. Trigger requires only local mount of an attacker-supplied filesystem image (USB, loopback, or removable media auto-mount). Reject the split whenever the chosen sp plus its declared size already extends past hdr1->used. This is the minimal fix; it preserves the existing hdr_find_split() contract and relies on the same out: cleanup path as the pre-existing error returns. A prior OOB read in the very same indx_insert_into_buffer() memmove was fixed in commit b8c44949044e (\"fs/ntfs3: Fix OOB read in indx_insert_into_buffer\") by tightening hdr_find_e(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdr_find_split(), not hdr_find_e(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72217", "url": "https://ubuntu.com/security/CVE-2026-72217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing xdr_buf_to_bvec() writes a bio_vec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it. rq_bvec, the array passed by nfsd_vfs_write(), is allocated to exactly rq_maxpages entries with no slack. The OOB store can land in adjacent slab memory; the bv_len and bv_offset fields written there are derived from client-supplied RPC payload sizes. Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72220", "url": "https://ubuntu.com/security/CVE-2026-72220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp->rq_procinfo->pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72221", "url": "https://ubuntu.com/security/CVE-2026-72221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: wait for in-flight TLS handshake callback when cancel loses race When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed. The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result. If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue. If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed. Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed to fire because handshake_complete() invokes svc_tcp_handshake_done() unconditionally once it has set HANDSHAKE_F_REQ_COMPLETED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72222", "url": "https://ubuntu.com/security/CVE-2026-72222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: pin svc_xprt across the asynchronous TLS handshake callback svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of(). Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done. The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry. Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all(). [cel: rewrote commit message to describe the actual change]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72277", "url": "https://ubuntu.com/security/CVE-2026-72277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the simpler thing for now and just reject everything that isn't memory.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72279", "url": "https://ubuntu.com/security/CVE-2026-72279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR KVM currently maps the L1 VNCR into the host stage-1 by relying entirely on the permissions of the guest stage-1. At the same time, it is entirely possible that the backing PFN is read-only (e.g. RO memslot), meaning that the L1 VNCR should use at most a read-only mapping. Cache the writability of the PFN in the VNCR TLB and use it to constrain the resulting fixmap permissions. Promote VNCR permission faults to an SEA in the case where the guest attempts to write to a read-only endpoint. Conveniently, this also plugs a page leak found by Sashiko [*] resulting from the early return for a read-only PFN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72288", "url": "https://ubuntu.com/security/CVE-2026-72288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling Hyunwoo Kim reports some really bad races should the following situation occur: - LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C If the last two race nicely enough, vgic_prune_ap_list() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows. The fix is two-fold: - Before dropping the irq and ap_list locks, take a reference on the irq - Do not try to handle migration of the pending bit: there is no expectation that this state is retained, as per the architecture With that, we're sure that the interrupt is still around, and we safely remove it from the AP list as it has no target at this stage (unless another interrupt fires, but that's another story).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "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-72317", "url": "https://ubuntu.com/security/CVE-2026-72317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: pin upper rpc_clnt across the TLS connect_worker The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt. The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported. Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one. The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72318", "url": "https://ubuntu.com/security/CVE-2026-72318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate DFS referral string offsets parse_dfs_referrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server. Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative max_len is then passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds. Validate each string offset before deriving the string pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72320", "url": "https://ubuntu.com/security/CVE-2026-72320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_lookup: fix catchall element handling with inverted lookups nft_lookup_eval() decides whether a lookup matched (`found`) from the direct set lookup and priv->invert before falling back to the catchall element used by interval sets (e.g. nft_set_rbtree) for the open-ended default range. Since `found` is never recomputed after `ext` is replaced by the catchall lookup, inverted lookups (NFT_LOOKUP_F_INV, \"!= @set\") can wrongly match or wrongly skip the catchall element, producing the wrong verdict. Fold the catchall lookup into `ext` before computing `found`, matching the order already used by nft_objref_map_eval().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72366", "url": "https://ubuntu.com/security/CVE-2026-72366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_create_write_req() to handle async cache object creation netfs_create_write_req() will skip caching if the fscache cookie is disabled, but this is a problem because async cache object creation might not have got far enough yet that has been enabled - thereby causing the call to fscache_begin_write_operation() to be skipped. Fix this by removing the checks on the cookie and delegating this to fscache_begin_write_operation().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72381", "url": "https://ubuntu.com/security/CVE-2026-72381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of fp->owner.name in durable handle owner check Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d (\"ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd\") made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized. BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8 Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72393", "url": "https://ubuntu.com/security/CVE-2026-72393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: don't cache shinfo across skb realloc fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb including the shared info. We can't use the pointer calculated before the call. BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0 Read of size 4 at addr ff110000262edd98 by task swapper/5/0 Call Trace: fbnic_tx_lso.isra.0+0x668/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 Allocated by task 8653: __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xcc/0x6c0 sock_alloc_send_pskb+0x327/0x3f0 __ip_append_data+0x188b/0x47a0 ip_make_skb+0x24a/0x300 udp_sendmsg+0x14d2/0x21e0 Freed by task 0: kfree+0x123/0x5a0 pskb_expand_head+0x36c/0xfa0 fbnic_tx_lso.isra.0+0x500/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 sch_direct_xmit+0x25b/0x1100 The buggy address belongs to the object at ff110000262edc40 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 344 bytes inside of freed 640-byte region [ff110000262edc40, ff110000262ede", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72398", "url": "https://ubuntu.com/security/CVE-2026-72398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: add INIT verification after cookie unpacking In SCTP handshake, the INIT chunk is initially processed by the server and embedded into the cookie carried in INIT-ACK. The client then returns this cookie via COOKIE-ECHO, where the server unpacks it and reconstructs the original INIT chunk. When cookie authentication is enabled, the cookie contents are protected against tampering, so reusing the unpacked INIT without re-verification is safe. However, when cookie authentication is disabled, the reconstructed INIT can no longer be trusted. In this case, the INIT must be explicitly validated after unpacking to avoid processing potentially tampered data. Add sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO processing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook()) when cookie_auth_enable is disabled. On failure, the new association is freed and the packet is discarded. Also tighten cookie validation in sctp_unpack_cookie() by verifying the embedded chunk type is SCTP_CID_INIT before treating it as an INIT chunk. Finally, update sctp_verify_init() to validate parameter bounds using the actual embedded INIT length instead of chunk->chunk_end, since the INIT stored in COOKIE-ECHO may not span the entire chunk buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72399", "url": "https://ubuntu.com/security/CVE-2026-72399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: check the number of BDs needed for xdp_frame The size of xdp_redirect_arr array is ENETC_MAX_SKB_FRAGS. However, the number of fragments contained in xdp_frame may be greater than or equal to ENETC_MAX_SKB_FRAGS, which will cause the access to xdp_redirect_arr to be out of bounds.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72429", "url": "https://ubuntu.com/security/CVE-2026-72429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix type confusion of dst_entry IOAM uses a dummy dst_entry(null_dst) to mark that the destination should not be changed after the transformation. This dst is stored in the IOAM lwt state and may be passed to dst_cache_set_ip6(). However, the IPv6 dst cache path eventually calls rt6_get_cookie(), which treats the dst_entry as part of a struct rt6_info. Since the null_dst was embedded directly as a struct dst_entry in struct ioam6_lwt, this resulted in an invalid cast and rt6_get_cookie() reading fields from the wrong object. In practice, the wrong cookie is not used while dst->obsolete is zero, but rt6_get_cookie() may also access per-cpu value when rt->sernum is zero. In this case, rt->sernum aliases ioam6_lwt::cache::reset_ts, which can become zero, making this a potential invalid pointer access. Fix this by embedding a full struct rt6_info for the dummy IPv6 route and passing its dst member to the dst APIs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72436", "url": "https://ubuntu.com/security/CVE-2026-72436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash types Sashiko pointed out that there are a few lockless RCU readers using test_bit() which is a relaxed atomic operation and provides no memory barrier guarantees. Use test_bit_acquire() instead where the operation may run parallel with add/del/gc, i.e. is not one from the next cases - protected by region lock - in a set destroy phase - in a new/temporary set creation phase", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72451", "url": "https://ubuntu.com/security/CVE-2026-72451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix xfrm state cache insertion race The xfrm input state cache insertion code checks the validity of the state before acquiring the global xfrm_state_lock. Thus it's possible for someone else to kill the state after it passed the validity check, and then the insertion will add the dead state to the cache. Fix this by moving the validity check inside the lock. This entire function is called on the input path, where BH must be off (e.g., the caller of this function xfrm_input acquires its spinlocks without disabling BH). So there is no need to disable BH here or take the RCU read lock. Remove both and replace them with an assertion that trips if BH is accidentally enabled on some future calling path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72472", "url": "https://ubuntu.com/security/CVE-2026-72472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: use nfsi->rwsem to protect traversal of the file lock list Lingfeng identified a bug and suggested two solutions, but both appear to have issues. Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case. Furthermore, after commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk. Regarding the bug fixed by commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), it has been resolved after commit 0460253913e5 (\"NFSv4: nfs4_do_open() is incorrectly triggering state recovery\") because all slots are drained before calling nfs4_do_reclaim, which prevents concurrent stateid changes along this path. Also, nfs_delegation_claim_locks does not cause this concurrency either since when _nfs4_proc_setlk is called with NFS_DELEGATED_STATE, no RPC is sent, so nfs4_lock_done is not called. Therefore, nfs4_lock_delegation_recall from nfs_delegation_claim_locks is the first time the stateid is set.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72473", "url": "https://ubuntu.com/security/CVE-2026-72473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decouple req recycling from RPC completion rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer. Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off. The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry. Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied. Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected. Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released. The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74310", "url": "https://ubuntu.com/security/CVE-2026-74310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/net: complete zerocopy ubufs only once vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74345", "url": "https://ubuntu.com/security/CVE-2026-74345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix endpoint/socket association handling Disassociating a socket from an endpoint via siw_socket_disassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within. This fixes a: BUG: KASAN: slab-use-after-free in siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1053 drivers/infiniband/sw/siw/siw_cm.c:1075) which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74361", "url": "https://ubuntu.com/security/CVE-2026-74361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: fix FDP fdpcidx bounds check The fdpcidx bounds check sets n = NUMFDPC + 1 but used > instead of >=, incorrectly accepting fdp_idx when it equals n (i.e. NUMFDPC + 1).", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74401", "url": "https://ubuntu.com/security/CVE-2026-74401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix add msg handle in send_queue ordered In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as \"before(mh->seq, seq)\" will stop to check for older sequence numbers that are ordered in the tail of \"node->send_queue\". The side effects of not having it correct ordered regarding \"before(mh->seq, seq)\" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74406", "url": "https://ubuntu.com/security/CVE-2026-74406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74428", "url": "https://ubuntu.com/security/CVE-2026-74428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix double unlock in rxrpc_recvmsg() Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74433", "url": "https://ubuntu.com/security/CVE-2026-74433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix UAF in rxgk_issue_challenge() Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74434", "url": "https://ubuntu.com/security/CVE-2026-74434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Don't move a peeked OOB message onto the pending queue rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so only unlink it from recvmsg_oobq and then move it onto pending_oobq or free it when the message is actually consumed.", "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-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-74439", "url": "https://ubuntu.com/security/CVE-2026-74439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clear Present bit before tearing down scalable-mode context entry device_pasid_table_teardown() zeroes the 128-bit scalable-mode context entry with context_clear_entry() while the Present bit is still set. This creates a window where the hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behavior or spurious faults. The context-cache invalidation is issued only after the entry has been zeroed, and intel_pasid_free_table() then frees the PASID directory pages, so the IOMMU can keep walking a stale Present=1 entry that points at freed memory. While x86 provides strong write ordering, the compiler may reorder the two 64-bit writes to the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Commit c1e4f1dccbe9d (\"iommu/vt-d: Clear Present bit before tearing down context entry\") fixed this exact pattern in domain_context_clear_one() and the copied-context path, but device_pasid_table_teardown() was not converted. Align it with the \"Guidance to Software for Invalidations\" in the VT-d spec, Section 6.5.3.3, using the same ownership handshake as the sibling fix: clear only the Present bit, flush it to the IOMMU, perform the context-cache invalidation, and only then zero the rest of the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2165483, 2165484, 2165407, 2166547, 2166443, 2166356, 2165872, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165407, 2165040, 2161748, 2163508, 2163214, 2162904, 2162045, 2164967, 2160082, 2164504, 2156316, 2164716, 2164516, 2163375, 2162803, 2163062, 2132119, 2163293, 2160200, 2158858, 2162704, 2162695, 2164666, 2164666, 2163121 ], "changes": [ { "cves": [ { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-68105", "url": "https://ubuntu.com/security/CVE-2026-68105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix kernel panic during driver load failure Avoid kernel panic if MES init fails during driver load. The KIQ ring is falsely marked as ready as ASICs that use MES, KIQ is owned by MES. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] Call Trace: gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280 __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53 (cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68109", "url": "https://ubuntu.com/security/CVE-2026-68109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68114", "url": "https://ubuntu.com/security/CVE-2026-68114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit e4d99e04b2e9b13b97d3b17804c735f62689db23)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68431", "url": "https://ubuntu.com/security/CVE-2026-68431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate minimum PDU size for transform requests The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68138", "url": "https://ubuntu.com/security/CVE-2026-68138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: serialize qdisc_rtab_list against concurrent get/put qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68082", "url": "https://ubuntu.com/security/CVE-2026-68082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix two unsafe bare decodes in decode_lockers() decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-08 10:16:00 UTC" }, { "cve": "CVE-2026-68159", "url": "https://ubuntu.com/security/CVE-2026-68159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68163", "url": "https://ubuntu.com/security/CVE-2026-68163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_vma_mapped: fix device-private PMD handling Commit 65edfda6f3f2 (\"mm/rmap: extend rmap and migration support device-private entries\") introduced the concept of device-private PMD entries, but did not correctly update the rmap walk code to account for them. As a result, when page_vma_mapped_walk() encounters device-private PMD entries, it takes no action other than to acquire the PMD lock and exit. However this is highly problematic for two reasons - firstly, device private entries possess a PFN so check_pmd() needs to be called to ensure an overlapping PFN range. Secondly, and more importantly, if PVMW_MIGRATION is set the caller assumes the returned entry is a migration entry, resulting in memory corruption when the caller tries to interpret the device private entry as such. In addition, commit 146287290023 (\"mm/huge_memory: implement device-private THP splitting\") allowed device private PMDs to be split like THP mappings, but again did not update this code path. As a result, we might race a PMD split prior to acquiring the PMD lock. This patch addresses all of these issues by invoking check_pmd(), ensuring PMVW_MIGRATION is not set and checks whether a split raced us we do for PMD THP and migration entries. Instead of checking for a subset of the cases after taking the pmd_lock(), put device-private along with pmd_trans_huge() and pmd_is_migration_entry(). Also remove thp_migration_supported() as it is already guarded by pmd_is_migration_entry(). [akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68166", "url": "https://ubuntu.com/security/CVE-2026-68166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: prevent registration of special VMAs Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68170", "url": "https://ubuntu.com/security/CVE-2026-68170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix stale skb->sk reference on subflow close The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68177", "url": "https://ubuntu.com/security/CVE-2026-68177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Delay module ref count for \"enable_event\" trigger Triggers are now delayed from freeing, but can still be triggered until after the RCU grace period has ended. The freeing of the enable_event data is put into the private_data_free() callback, but the put of the module refcount is done immediately. It is possible that if a module is removed that has an event that would enable (or disable) it is still active, it can read the data of the module after it is removed causing a use-after-free bug. Move the trace_event_put_ref() that releases the module into the delayed callback so that the module can not be removed until any reference to its events are finished.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68191", "url": "https://ubuntu.com/security/CVE-2026-68191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix NULL pointer dereference in rhash table destroy When unbinding the ath12k driver, kernel NULL pointer dereferences occur in irq_work_sync() called from rhashtable_destroy(). Two hash tables are affected: 1. ath12k_link_sta hash table in ath12k_base 2. ath12k_dp_link_peer hash table in ath12k_dp The issue happens because the destroy functions are called unconditionally in cleanup paths, but the hash tables are only initialized late in their respective init functions. If the device was never fully started or if the init functions failed before initializing the hash tables, the pointers will be NULL. The issues are always reproducible from a VM because the MSI addressing initialization is failing. Call trace for ath12k_link_sta_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_link_sta_rhash_tbl_destroy+0x19/0x40 [ath12k] ath12k_core_stop+0xe/0x80 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Call trace for ath12k_dp_link_peer_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_dp_link_peer_rhash_tbl_destroy+0x29/0x50 [ath12k] ath12k_dp_cmn_device_deinit+0x21/0x140 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Fix this by adding NULL checks before calling rhashtable_destroy() in both destroy functions. The NULL check approach was chosen because the rhashtable pointer serves as the initialization state indicator. The init can fail at various points, leaving some components uninitialized. Checking the pointer directly is simpler than adding separate state flags that would need synchronization.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64586", "url": "https://ubuntu.com/security/CVE-2026-64586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: drain bus_reset work on device removal brcmf_fw_crashed() and the debugfs \"reset\" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs \"reset\" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. 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-68208", "url": "https://ubuntu.com/security/CVE-2026-68208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: Fix the error code of devm_kzalloc() in vip_probe_slice() In vip_probe_slice(), the error check for devm_kzalloc() incorrectly uses PTR_ERR_OR_ZERO() which returns 0 for NULL pointer. Return -ENOMEM for devm_kzalloc() failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68224", "url": "https://ubuntu.com/security/CVE-2026-68224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mali-c55: Fix possible ERR_PTR in enable_streams The media_pad_remote_pad_unique() function returns either a valid pointer or an ERR_PTR() on failure (-ENOTUNIQ if multiple links are enabled, -ENOLINK if no connected pad is found). The return value was assigned directly to isp->remote_src and dereferenced in the next line without checking for errors, which could lead to an ERR_PTR dereference. Add proper error checking with IS_ERR() before dereferencing the pointer. Also set isp->remote_src to NULL on error to maintain consistency with other error paths in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68237", "url": "https://ubuntu.com/security/CVE-2026-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: fix indefinite fence wait during GPU reset pre_reset only force-completes fences of MAPPED queues. A queue in any other state (e.g. mid-eviction) keeps its last_fence pending; after a GPU reset that fence never signals, so the eviction/suspend worker and process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and wedge the machine: INFO: task kworker/6:28 blocked for more than 120 seconds. Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu] Call Trace: dma_fence_wait_timeout+0x7e/0x130 amdgpu_userq_evict+0x67/0x140 [amdgpu] amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu] process_scheduled_works+0xa6/0x420 Force-complete every queue's fence regardless of state. The unmap and mark-hung step stays gated on MAPPED, since unmapping a queue that is not mapped is invalid. (cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68240", "url": "https://ubuntu.com/security/CVE-2026-68240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: publish dpagemap early to avoid device mapping leak on error drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68242", "url": "https://ubuntu.com/security/CVE-2026-68242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix NULL deref on sched_engine alloc failure Avoid using intel_context_put() before intel_context_init() in execlists_create_virtual() as the kref_put() inside would lead to NULL deref on the IOCTL path when sched_engine allocation fails. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68254", "url": "https://ubuntu.com/security/CVE-2026-68254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: require valid min/max vfreq for VRR Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68436", "url": "https://ubuntu.com/security/CVE-2026-68436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use kvzalloc to allocate struct dc struct dc has grown large over time (most of it the two inlined dc_scratch_space copies) and now sits close to the page allocator's 4 MiB contiguous allocation limit. Its actual size is not fixed by the source alone, it also depends on the compiler and the .config, so it can easily cross 4 MiB, e.g. with a newer GCC or a config change. dc_create() allocates it with kzalloc(). Once struct dc exceeds 4 MiB the request is rounded up to order 11 (8 MiB), which is above MAX_PAGE_ORDER, so the page allocator warns and returns NULL. dc_create() then fails, DM init fails and amdgpu probe aborts with -EINVAL: WARNING: mm/page_alloc.c:5197 at __alloc_frozen_pages_noprof+0x2f9/0x380 dc_create+0x38/0x660 [amdgpu] amdgpu_dm_init+0x2d9/0x510 [amdgpu] dm_hw_init+0x1b/0x90 [amdgpu] amdgpu_device_init.cold+0x150d/0x1e13 [amdgpu] amdgpu_driver_load_kms+0x19/0x80 [amdgpu] amdgpu_pci_probe+0x1e2/0x4c0 [amdgpu] dc_create() then returns NULL and DM init fails, which aborts the whole GPU init and makes amdgpu probe fail with -EINVAL (\"hw_init of IP block failed -22\"), leaving the display unusable. The subsequent amdgpu_irq_put() warnings during teardown are just fallout of unwinding a half-initialized device. struct dc is a software-only bookkeeping structure that is never handed to hardware DMA and is only ever kept as an opaque pointer, so it does not require physically contiguous memory. Allocate it with kvzalloc() (and free it with kvfree()) so that the allocator can fall back to vmalloc() when a contiguous allocation of that size is not available, which also avoids the MAX_PAGE_ORDER warning entirely. v2: - Rebase to amd-staging-drm-next. (cherry picked from commit 991e0516a8072f2292681c6ae98a924ab0e32575)", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68447", "url": "https://ubuntu.com/security/CVE-2026-68447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size from hardware without bounding it to the allocated BO region. If the HW field is larger than the queue's control stack allocation, memcpy reads past the BO into adjacent GTT memory and can leak kernel data to userspace. Store the page-aligned control stack BO size in mqd_manager and clamp checkpoint copies and reported checkpoint sizes to min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound for multi-XCC v9.4.3 checkpoint layout. (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3)", "cve_priority": "high", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68264", "url": "https://ubuntu.com/security/CVE-2026-68264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: Reset current_op in xe_pt_update_ops_init() xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it. After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind. Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry. Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(). v2 (Matt): - Add details in commit message. - Add Fixes tag and Cc to stable@vger.kernel.org (cherry picked from commit 046045543e530605c441063535e7dca0075369a6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68265", "url": "https://ubuntu.com/security/CVE-2026-68265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO's tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference (cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68267", "url": "https://ubuntu.com/security/CVE-2026-68267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists Unconditionally whitelisting OA registers is a security violation. Set RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers don't get whitelisted by default after probe, gt reset, resume and engine reset. (cherry picked from commit 90511bdcfda97211c01f1d945d4ea616578d8fca)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68273", "url": "https://ubuntu.com/security/CVE-2026-68273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68274", "url": "https://ubuntu.com/security/CVE-2026-68274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix buffer overflow in steered register list allocation The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt->fuse_topo.g_dss_mask, ...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68283", "url": "https://ubuntu.com/security/CVE-2026-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free freeing trigger private data Commit 61d445af0a7c (\"tracing: Add bulk garbage collection of freeing event_trigger_data\") moved the kfree() of event_trigger_data to a kthread that runs tracepoint_synchronize_unregister() before freeing. That removed the synchronization the trigger .free callbacks used to get implicitly and inline from trigger_data_free(). event_hist_trigger_free(), event_hist_trigger_named_free() and event_enable_trigger_free() free their satellite data (hist_data, cmd_ops, enable_data) right after trigger_data_free() returns. With the synchronization now deferred to the kthread, a concurrent tracepoint handler can still reach that data through the list_del_rcu()'d trigger, causing a use-after-free. The histogram teardown must stay synchronous: remove_hist_vars() and unregister_field_var_hists() have to detach a synthetic event from the histogram before the trigger-removal write returns, otherwise a following command races in and the synthetic-event removal fails with -EBUSY, as the trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait with the correct barrier - tracepoint_synchronize_unregister(), matching the free kthread - before freeing. The enable trigger has no such synchronous requirement, and a blocking synchronize there would re-serialize the path that commit deliberately deferred. Give it an optional private_data_free() callback that the free kthread runs after its grace period, and free enable_data from there.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68286", "url": "https://ubuntu.com/security/CVE-2026-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68287", "url": "https://ubuntu.com/security/CVE-2026-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix size calculations for 64-bit attributes net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68288", "url": "https://ubuntu.com/security/CVE-2026-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68289", "url": "https://ubuntu.com/security/CVE-2026-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68291", "url": "https://ubuntu.com/security/CVE-2026-68291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix max_vport related crash on allocation error during init Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000 [ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000 [ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20 [ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000 [ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0 [ 320.417385] PKRU: 55555554 [ 320.417398] Call Trace: [ 320.417412] [ 320.417429] pci_device_remove+0x42/0xb0 [ 320.417459] device_release_driver_internal+0x1a9/0x210 [ 320.417492] driver_detach+0x4b/0x90 [ 320.417516] bus_remove_driver+0x70/0x100 [ 320.417539] pci_unregister_driver+0x2e/0xb0 [ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0 [ 320.417592] ? kmem_cache_free+0x31e/0x550 [ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190 [ 320.417644] ? do_syscall_64+0x38/0x6b0 [ 320.417665] do_syscall_64+0xc8/0x6b0 [ 320.417683] ? clear_bhb_loop+0x30/0x80 [ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 320.417727] RIP: 0033:0x7f963bb30beb", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68303", "url": "https://ubuntu.com/security/CVE-2026-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hvs/v3d: Fix null dereference in unbind The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68312", "url": "https://ubuntu.com/security/CVE-2026-68312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and cifs_close_deferred_file_under_dentry(), when a pending deferred close is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to add the file to the local processing list may fail under memory pressure. The loop breaks immediately, but the cancelled work is no longer pending (it would have called _cifsFileInfo_put()), and the cfile is never added to file_head for processing. The cifsFileInfo reference and the open server handle both leak. Fix by saving the cfile that failed allocation in a local variable, breaking as before, and calling _cifsFileInfo_put() on it after releasing the lock. Any files later in the iteration are unaffected since their deferred work is still pending and will fire normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68316", "url": "https://ubuntu.com/security/CVE-2026-68316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Fix element size accounting for cmd stream validation There are 2 issues with the element size handling in the command stream validation which result in too small of a size calculated when the element size is 16/32/64 bits. For NHWC format, the element size is simply missing from the calculation. The bitfield for the element size is different between IFM/IFM2 and OFM. IFM and IFM2 encode the precision in parameter bits 2:3, while OFM uses bits 1:2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68440", "url": "https://ubuntu.com/security/CVE-2026-68440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix heap overflow when reading module EEPROM txgbe_read_eeprom_hostif() always copies round_up(length, 4) bytes into the caller buffer, which ethtool allocates with exactly 'length' bytes. A non-4-aligned length therefore causes an out-of-bounds write. Copy only the remaining bytes on the final dword instead.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68323", "url": "https://ubuntu.com/security/CVE-2026-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: serialize udp bearer replicast list updates tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68441", "url": "https://ubuntu.com/security/CVE-2026-68441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected. This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d (\"bpf: add bpf_redirect() helper\"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available. commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs. Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a wrapper around tcf_classify() for use by qdisc classify functions and tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT, the wrapper converts it to TC_ACT_SHOT, dropping the packet rather than letting it continue silently. Dropping is preferred over letting the packet through because the user immediately sees packet loss. Silently passing the packet through would hide the problem and leave the user wondering why their redirect is not working. The clsact fast path, tc_run() continues to call tcf_classify() directly and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by sch_handle_egress/ingress() calling skb_do_redirect() as before.", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68337", "url": "https://ubuntu.com/security/CVE-2026-68337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject redirect helpers without a bpf_net_context The bpf_redirect*() helpers and skb_do_redirect() obtain the per-task bpf_redirect_info via bpf_net_ctx_get_ri(), which dereferences the current->bpf_net_context unconditionally. That context is established on the paths that run tc BPF such as sch_handle_{ingress,egress}(), *except* for the case where {cls,act}_bpf was attached to a proper qdisc. A program running from there reaches the NULL deref in two ways: * It calls bpf_redirect() directly, which dereferences the context at the top of the helper: tc qdisc add dev eth0 root handle 1: red limit 1MB min 10KB max 20KB \\ avpkt 1000 burst 100 qevent early_drop block 10 tc filter add block 10 pref 1 bpf obj redirect.o * It simply returns TC_ACT_REDIRECT without helper call: tcf_qevent_handle() then dispatches to skb_do_redirect(), which dereferences the context Rather than extending bpf_net_context management into the qdisc path, make the redirect helpers refuse to operate when no context exists, and have tcf_qevent_handle() drop a TC_ACT_REDIRECT verdict instead of calling skb_do_redirect(). Previous behaviour was a crash, so nothing regresses by not supporting it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68345", "url": "https://ubuntu.com/security/CVE-2026-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm_mpam: guard MBWU state before adding it to garbage __destroy_component_cfg() adds each RIS mbwu_state object to the MPAM garbage list when destroying component configuration. However, mbwu_state is allocated per RIS and only for RISes with MBWU monitors. A component can therefore have comp->cfg allocated while some RISes still have ris->mbwu_state set to NULL. Passing a NULL mbwu_state to add_to_garbage() dereferences the NULL pointer inside the macro. Skip RISes that do not have an mbwu_state object before adding them to the garbage list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68347", "url": "https://ubuntu.com/security/CVE-2026-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68375", "url": "https://ubuntu.com/security/CVE-2026-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle partially initialized auxiliary devices bnxt_aux_devices_init() calls auxiliary_device_init() before all fields used by bnxt_aux_dev_release() are initialized. After auxiliary_device_init() succeeds, later errors must unwind with auxiliary_device_uninit(), which invokes the release callback. The release callback assumes that aux_priv->id, aux_priv->edev, edev->net and edev->ulp_tbl are all populated. If allocation fails after auxiliary_device_init(), the release path can otherwise dereference or clear partially initialized state. Allocate and attach the bnxt_en_dev and ULP table before calling auxiliary_device_init(), so the release callback only sees a fully initialized auxiliary private object. If auxiliary_device_init() itself fails, free those allocations directly because device_initialize() has not run and the release callback will not be invoked. 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-68382", "url": "https://ubuntu.com/security/CVE-2026-68382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Hold device ref until queue teardown completes GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock. Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending. Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work. With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. Replace the fini wait with an assertion and remove the unused fini_wq. v2: - Rebase v3: - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt) - Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt) - Drop separate deferred drm_dev_put worker. - Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini(). v4: - Replace the guc_submit_sw_fini() wait with an assertion and remove the now-unused fini_wq. (sashiko) v5: - Move destroy work to a module-lifetime Xe workqueue instead of system_dfl_wq. (Matt) - Flush the module-lifetime destroy workqueue during PCI remove to preserve the old device-remove wait semantics. v6: - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid letting it outlive the xe_device/drm_device. (Sashiko) - Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work can be queued from the reclaim path. v7: - Drop the per-device xe->destroy_wq and use the module-level destroy WQ for SVM pagemap destroy as well. (Matt) - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*() helpers because the WQ is no longer exec-queue specific. (Matt) v8: - Rebase. v9: - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM destroy_wq because it can be queued from reclaim and embeds the dev_pagemap used by devres teardown. (Sashiko) - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM from it. - Update the module-WQ kdoc to document the GuC/SVM split. v10: - Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the workqueue allocation warning. v11: - Drop the SVM pagemap destroy comment as it was revision-specific. (Thomas) v12: - Rebase. (cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68383", "url": "https://ubuntu.com/security/CVE-2026-68383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Keep scheduler timeline name alive The scheduler keeps a pointer to the timeline name, but q->name is freed with the exec queue while scheduler fences can still reference it. Store the name in struct xe_guc_exec_queue so it shares the scheduler's RCU-deferred lifetime. (cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68390", "url": "https://ubuntu.com/security/CVE-2026-68390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups hci_conn_params_lookup requires hdev->lock be held, otherwise the list iteration or param access is not safe. Hold hdev->lock for params lookups in hci_sync.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-2026-68404", "url": "https://ubuntu.com/security/CVE-2026-68404", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: use wiphy work for socket owner autodisconnect nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68367", "url": "https://ubuntu.com/security/CVE-2026-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: synchronize delayed set_alt with teardown The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68095", "url": "https://ubuntu.com/security/CVE-2026-68095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse-uring: fix race between registration and connection abortion This fixes this race: - thread a: io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref yet - thread b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() is a no-op due to queue ref being 0 - thread a: grabs the queue_ref, queue_ref is now 1, rest of fuse_uring_do_register() logic executes - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs and calls \"wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);\" The abort/unmount thread will hang indefinitely in unkillable state as nothing will decrement queue_refs or wake stop_waitq, and the ring, queue, and ent are leaked. Fix this by checking fch->connected under fch->lock after the created ent has grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either release the queue ref and wake up stop_waitq (in case fuse_chan_wait_aborted() is already waiting) in fuse_uring_do_register() when we detect !fch->connected, or if the connection is aborted after the check, it is guaranteed that the async teardown worker will be running in the background cleaning up ents and decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-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-68173", "url": "https://ubuntu.com/security/CVE-2026-68173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: wait on ublk_dev_ready() instead of ub->completion ub->completion is only re-armed by a successful START_USER_RECOVERY. If the ublk server sends END_USER_RECOVERY without one - e.g. its START failed with -EBUSY and the error was ignored - the wait is satisfied by the stale completion of the previous recovery cycle, and the device is marked LIVE and the requeue list kicked while the FETCH stream is still running and ubq->canceling is still set. The kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it again via __ublk_abort_rq(), and after the last FETCH clears ->canceling nothing ever kicks the requeue list again: the request is stranded there while holding its tag. If it is the flush machinery's flush_rq, every subsequent fsync piles up in uninterruptible sleep and teardown hangs on tag draining. This matches a report of a lost PREFLUSH with ext4 on top of ublk after daemon crash recovery. ub->completion is an edge-triggered latch used as a proxy for the level condition \"every queue has fetched all I/O commands\", which can regress (F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop it and wait on the real condition instead: the new helper ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then re-checks it under ub->mutex, waiting again on regression, and returns with the mutex held and readiness guaranteed. Readiness becomes true in the same ub->mutex critical section that clears the last queue's ->canceling, so END_USER_RECOVERY marks the device LIVE and kicks the requeue list strictly after ->canceling clears. The wait stays interruptible, so a server whose daemon died can still be signalled out. For ublk_ctrl_start_dev() this replaces the fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting until the device is ready again.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68113", "url": "https://ubuntu.com/security/CVE-2026-68113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68118", "url": "https://ubuntu.com/security/CVE-2026-68118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: challenge ACK for non-exact RST in SYN-RECEIVED The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68120", "url": "https://ubuntu.com/security/CVE-2026-68120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtase: Workaround for TX hang caused by hardware packet parsing The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission.", "cve_priority": "medium", "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-68122", "url": "https://ubuntu.com/security/CVE-2026-68122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix peer refcount leak in TCP error paths When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&peer->tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object. The race window: CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error): ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2 schedule_work() <- queued schedule_work() <- NO-OP (work already pending) ovpn_tcp_peer_del_work runs: ovpn_peer_del() ovpn_peer_put() <- refcnt+1 <- peer never freed Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68128", "url": "https://ubuntu.com/security/CVE-2026-68128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: reject out-of-range ptype in ice_parser_profile_init set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from providing ptype >= 1024 through VIRTCHNL, resulting in a write past the end of the bitmap and a kernel page fault. Reproduced with a custom kernel module injecting a crafted VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1. crash_parser: ice_parser_profile_init @ ffffffffc0d61b60 crash_parser: setting ptype=0xffff (max valid=1023) crash_parser: calling ice_parser_profile_init -- expect OOB crash! BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace: ? __pfx_ice_parser_profile_init+0x10/0x10 [ice] crash_init+0x127/0xff0 [crash_parser] do_one_initcall+0x45/0x310 do_init_module+0x64/0x270 init_module_from_file+0xcc/0xf0 idempotent_init_module+0x17b/0x280 __x64_sys_finit_module+0x6e/0xe0 Bail out early with -EINVAL when ptype is out of range.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68132", "url": "https://ubuntu.com/security/CVE-2026-68132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: super: fix emergency thaw deadlock on frozen block devices do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68133", "url": "https://ubuntu.com/security/CVE-2026-68133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP Call Trace during PTP release If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will result in the following PTP release call trace during driver unload: kernel BUG at lib/list_debug.c:52! ice_ptp_release+0x332/0x3c0 [ice] ice_deinit_features.part.0+0x10e/0x120 [ice] ice_remove+0x100/0x220 [ice] This was observed when passing PF1 through to a VM. ice_ptp_init() fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT. Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and returning without error, preventing the invalid state transition to ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from ICE_PTP_RESETTING after a failed rebuild.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68134", "url": "https://ubuntu.com/security/CVE-2026-68134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: ptp_s390: Add missing facility check Only register the physical clock when facility 28 is installed and PTFF QAF returns that PTFF QPT is available.", "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-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-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-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-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-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-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-68150", "url": "https://ubuntu.com/security/CVE-2026-68150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/super: fix emergency thaw double-unlock of s_umount do_thaw_all() iterates over all superblocks via __iterate_supers() with SUPER_ITER_EXCL, which acquires s_umount exclusively before calling the callback and releases it afterwards. However, the callback do_thaw_all_callback() calls thaw_super_locked() which unconditionally releases s_umount on every code path. This results in a second unlock attempt in __iterate_supers() that corrupts the rwsem state, triggering a DEBUG_RWSEMS warning: [ 182.601148] sysrq: Emergency Thaw of all frozen filesystems [ 182.601865] ------------[ cut here ]------------ [ 182.602375] DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff99b1011e5870, owner = 0x0, curr 0xffff99b101b06c80, list not empty [ 182.603817] WARNING: kernel/locking/rwsem.c:1412 at up_write+0xa3/0x170, CPU#2: kworker/2:1/53 [ 182.604578] Modules linked in: [ 182.604864] CPU: 2 UID: 0 PID: 53 Comm: kworker/2:1 Not tainted 7.2.0-rc4-00001-gbd3bd93ea98a-dirty #4 PREEMPT(lazy) [ 182.605711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014 [ 182.606417] Workqueue: events do_thaw_all [ 182.606750] RIP: 0010:up_write+0xaf/0x170 [ 182.607076] Code: 19 3a 92 48 0f 44 c2 48 8b 55 08 48 8b 55 00 4c 8b 45 08 48 8b 55 00 48 8d 3d ad 91 e0 01 48 8b 4d 20 50 48 c7 c6 f0 8c 26 92 <67> 48 0f b9 3a e8 d7 93 4e 00 58 eb 81 48 83 7f 18 00 48 c7 c2 8d [ 182.608563] RSP: 0018:ffffb670001d7e08 EFLAGS: 00010246 [ 182.609007] RAX: ffffffff92349e8d RBX: 0000000000000000 RCX: ffff99b1011e5870 [ 182.609595] RDX: 0000000000000000 RSI: ffffffff92268cf0 RDI: ffffffff92914d10 [ 182.610283] RBP: ffff99b1011e5870 R08: 0000000000000000 R09: ffff99b101b06c80 [ 182.610847] R10: ffff99b10139a808 R11: fefefefefefefeff R12: 0000000000000000 [ 182.611414] R13: ffffffff90cf74d0 R14: 0000000000000000 R15: ffff99b1011e5800 [ 182.612009] FS: 0000000000000000(0000) GS:ffff99b1eaaee000(0000) knlGS:0000000000000000 [ 182.612670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 182.613146] CR2: 00000000005c631c CR3: 00000000013ee000 CR4: 00000000000006f0 [ 182.613722] Call Trace: [ 182.613946] [ 182.614130] __iterate_supers+0x128/0x150 [ 182.614463] do_thaw_all+0x1b/0x30 [ 182.614759] process_scheduled_works+0xbb/0x3f0 [ 182.615150] ? __pfx_worker_thread+0x10/0x10 [ 182.615499] worker_thread+0x129/0x270 [ 182.615816] ? __pfx_worker_thread+0x10/0x10 [ 182.616201] kthread+0xe2/0x120 [ 182.616469] ? __pfx_kthread+0x10/0x10 [ 182.616792] ret_from_fork+0x15b/0x240 [ 182.617115] ? __pfx_kthread+0x10/0x10 [ 182.617426] ret_from_fork_asm+0x1a/0x30 [ 182.617761] [ 182.617968] ---[ end trace 0000000000000000 ]--- [ 182.618412] Emergency Thaw complete Fix this by switching to SUPER_ITER_UNLOCKED and acquiring s_umount in the callback via super_lock_excl() before calling thaw_super_locked(). This matches the locking pattern expected by thaw_super_locked() and eliminates the double unlock. While at it, remove the dead 'return;' at the end of do_thaw_all_callback().", "cve_priority": "low", "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-68152", "url": "https://ubuntu.com/security/CVE-2026-68152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: fix use-after-free in AMT delayed works When an AMT device is removed, pending delayed works can still access the freed amt_dev structure, which may result in kernel crashes or memory corruption. amt_dev_stop() cancels req_wq and discovery_wq with cancel_delayed_work_sync(), but these works can be scheduled again from event_wq after the cancellation. This allows delayed works to access the freed amt_dev structure after the netdev has been released. The following is a simple race scenario: CPU0 CPU1 amt_dev_stop() cancel_delayed_work_sync() amt_event_work() mod_delayed_work(req_wq) free netdev req_wq accesses freed amt_dev Use disable_delayed_work_sync() in amt_dev_stop() to prevent req_wq and discovery_wq from being queued again and wait for running work items to complete. The delayed works are disabled after initialization in amt_newlink() and enabled only when the device is successfully opened. This keeps the delayed work lifecycle synchronized with the lifetime of the AMT device.", "cve_priority": "high", "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-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-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-68168", "url": "https://ubuntu.com/security/CVE-2026-68168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix afs_edit_dir_remove() to get, not find, block 0 Fix afs_edit_dir_remove() to use afs_dir_get_block() to get block 0 rather than afs_dir_find_block() as the latter caches the found block in the afs_dir_iter and may[*] switch out the page it's on if another afs_dir_find_block() is done. This parallels what afs_edit_dir_add() does. [*] There's more than one block per page.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68169", "url": "https://ubuntu.com/security/CVE-2026-68169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: userspace: fix use-after-free in get_local_id In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a \"not found\" sentinel.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68172", "url": "https://ubuntu.com/security/CVE-2026-68172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: make huge_ptep_get handled unaligned addresses huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma). The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned. On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map or into a hole, dereference a VA not mapped into the kernel pgtables and cause kernel panic. Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68174", "url": "https://ubuntu.com/security/CVE-2026-68174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix union collision of module and refcnt for dynamic events In 'struct trace_event_call', the 'module' pointer and the 'refcnt' atomic variable share the same memory space in a union. For dynamic events, the union member is 'refcnt', which acts as an active reference counter. When a dynamic event (such as kprobe, uprobe, fprobe, eprobe, or wprobe) has a non-zero reference count (e.g. due to active event triggers or perf attachments), its 'call->module' evaluates to a small non-zero integer instead of NULL. When filtering or setting events for a specific module (e.g., writing ':mod:' to 'set_event'), the code in '__ftrace_set_clr_event_nolock()' and 'update_event_fields()' reads 'call->module' directly without checking whether the event is dynamic. This causes the kernel to treat the small integer (refcnt) as a 'struct module' pointer, leading to a NULL/invalid pointer dereference (Oops) when dereferencing the module name. Fix this by ensuring that the 'TRACE_EVENT_FL_DYNAMIC' flag is checked before treating 'call->module' as a valid pointer in these code paths.", "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-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-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-68434", "url": "https://ubuntu.com/security/CVE-2026-68434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms Commit b1b4efea05a5 (\"serial: 8250_mid: Disable DMA for selected platforms\") replaced the dnv_board setup and exit callbacks with PTR_IF(false, ...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. Fix this by adding the missing NULL checks before calling the setup and exit callbacks.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17: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-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-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16: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-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-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-68198", "url": "https://ubuntu.com/security/CVE-2026-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix use-after-free in aggr_reset_state() The aggr_reset_state() function uses timer_delete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggr_module_destroy(). If the timer callback (aggr_timeout) is executing when aggr_reset_state() is called, the callback will continue to access aggr_conn fields like rx_tid[] and stat[] which may be freed immediately after by kfree(aggr_info->aggr_conn) in aggr_module_destroy(). Additionally, the timer callback can re-arm itself via mod_timer() while aggr_reset_state() is running, creating a more complex race condition. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "high", "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-68200", "url": "https://ubuntu.com/security/CVE-2026-68200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: don't re-enter an instance callback that is still running The userspace-driven timer (utimer) TRIGGER ioctl calls snd_timer_interrupt() directly with no serialization, so two threads triggering the same utimer can run snd_timer_interrupt() on one snd_timer concurrently. snd_timer_process_callbacks() drops timer->lock around each instance callback and marks the in-flight callback with the single SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that bit to drain an in-flight callback before freeing the instance. The bit cannot represent two concurrent callbacks: when a second interrupt re-queues an instance whose callback is still running, both run at once, the first to finish clears the bit, and the close-path drain then frees the instance (and its callback_data) while the other callback is still live - a use-after-free reachable by any user able to open /dev/snd/timer, both via a user timer instance and via a sequencer queue timer bound to the utimer. snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so a concurrent interrupt already observes it under the lock. Skip re-queuing an instance (and its slaves) to the ack/sack list while its callback is in flight; the accumulated pticks are delivered on the next tick, so no event is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68201", "url": "https://ubuntu.com/security/CVE-2026-68201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: drain a slave's callback before its master detaches it snd_timer_close_locked() drains the closing instance's own in-flight callback (IFLG_CALLBACK) before freeing it, but not its slaves'. When a master instance is closed, remove_slave_links() clears each slave's ->timer; the slave's own close then reads timer == NULL and takes the branch that skips the drain entirely (snd_timer_stop_slave() also no-ops on a NULL timer). So a slave whose callback is still running when the master is closed is freed underneath the live callback, leading to use-after-free. Drain the slaves too before remove_slave_links() severs them. snd_timer_stop() has already taken this instance off the active list, so no new slave callback can be queued. Take the slaves off the ack list so a pending one can't fire either, then wait for any that is already in flight.", "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-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-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-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-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-68211", "url": "https://ubuntu.com/security/CVE-2026-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32-dcmipp: 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. dcmipp_bytecap_start_streaming() returned -EINVAL when the source subdevice could not be resolved from the media graph, before pm_runtime_resume_and_get() and media_pipeline_start() had been called. The remaining error paths already converge on the err_buffer_done label, which calls dcmipp_bytecap_all_buffers_done(..., VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate err_pm_put / err_media_pipeline_stop 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": "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-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-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-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-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-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-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-68230", "url": "https://ubuntu.com/security/CVE-2026-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: amlogic-c3: Add validations for ae and awb config Avoid invalid memory access if the zones_num is bigger than zone_weight. This patch fixes the following smatch errors: drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max", "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-68232", "url": "https://ubuntu.com/security/CVE-2026-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path.", "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-68233", "url": "https://ubuntu.com/security/CVE-2026-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Shut down BO cache timer before teardown The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20: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-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-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-68238", "url": "https://ubuntu.com/security/CVE-2026-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Release VFCT ACPI table reference amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68239", "url": "https://ubuntu.com/security/CVE-2026-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Account for NULL and handle pages in ttm_pool_backup Pages in ttm_pool_backup can be NULL or backup handles (ttm_backup_page_ptr_is_handle()), neither of which can be passed to set_pages_array_wb() or freed. Add a dedicated WB pass before the dma/purge loop that walks allocations using the same i += num_pages stride, skipping NULL and handle entries, and calls set_pages_array_wb() once per contiguous run of real pages. Apply the same NULL/handle guard to the dma/purge loop. Fixes the following oops: Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI RIP: 0010:__cpa_process_fault+0xf8/0x770 RSP: 0018:ffffc90000a87718 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34 RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0 R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000 R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0 FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0 PKRU: 55555554 Call Trace: __change_page_attr_set_clr+0x989/0xe90 ? __purge_vmap_area_lazy+0x6c/0x3a0 ? _vm_unmap_aliases+0x250/0x2a0 set_pages_array_wb+0x7f/0x120 ttm_pool_backup+0x4c9/0x5b0 [ttm] ? dma_resv_wait_timeout+0x3b/0xf0 ttm_tt_backup+0x32/0x60 [ttm] ttm_bo_shrink+0x66/0x110 [ttm] xe_bo_shrink_purge+0x12b/0x1b0 [xe] xe_bo_shrink+0xbb/0x270 [xe] __xe_shrinker_walk+0xf7/0x160 [xe] xe_shrinker_walk+0x9d/0xc0 [xe] xe_shrinker_scan+0x11f/0x210 [xe] do_shrink_slab+0x13b/0x270 shrink_slab+0xf1/0x400 shrink_node+0x352/0x8a0 balance_pgdat+0x32c/0x700 kswapd+0x205/0x2f0 ? __pfx_autoremove_wake_function+0x10/0x10 ? __pfx_kswapd+0x10/0x10 kthread+0xd1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1b1/0x200 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68241", "url": "https://ubuntu.com/security/CVE-2026-68241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/mst: limit DP MST ESI service loop The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto. (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)", "cve_priority": "medium", "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-68245", "url": "https://ubuntu.com/security/CVE-2026-68245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only valid while the lock is still being held. Once xa_unlock_irqrestore is called and returned, the pointer is no longer under lock and is subject to modification. Since, the caller still dereferences vm->task_info in amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a use after unlock problem. Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid() through removing the amdgpu_vm_get_vm_from_pasid() function from amdgpu_vm.c and making the relevant code inline to hold the lock while it is still in use. (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)", "cve_priority": "high", "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-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-68252", "url": "https://ubuntu.com/security/CVE-2026-68252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68253", "url": "https://ubuntu.com/security/CVE-2026-68253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)", "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-68257", "url": "https://ubuntu.com/security/CVE-2026-68257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix 32-bit overflow in CWSR total size calculation total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68258", "url": "https://ubuntu.com/security/CVE-2026-68258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on CRIU restore queue type and mqd size We weren't checking whether the values provided in the private data in kfd CRIU restore were within bounds. For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it. For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations. (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)", "cve_priority": "low", "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-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-68266", "url": "https://ubuntu.com/security/CVE-2026-68266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68268", "url": "https://ubuntu.com/security/CVE-2026-68268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Return error on non-migratable faults requiring devmem Non-migratable faults that require devmem incorrectly jump to the 'out' label, which squashes the error code intended to be returned to the upper layers. Fix this by returning -EACCES instead. (cherry picked from commit c4508edb2c723de93717272488ea65b165637eac)", "cve_priority": "medium", "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-68270", "url": "https://ubuntu.com/security/CVE-2026-68270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Avoid possible truncation with calculating visible size Calculating the visible size of the system framebuffer can result in truncation of the result. The calculation uses 32-bit arithmetics, which can overflow if the values for height and stride are large. Fix the issue by multiplying with mul_u32_u32().", "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-68275", "url": "https://ubuntu.com/security/CVE-2026-68275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks up the bo_va for the buffer object in the caller's VM via amdgpu_vm_bo_find(), but uses the returned pointer without checking it. amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM, which is the normal case for a BO that has never been mapped. The result is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which expands to list_for_each_entry(mapping, &(bo_va)->valids, list) and dereferences bo_va, causing a NULL pointer dereference. This is reachable by any process able to issue the ioctl (render group) simply by requesting mapping info for an unmapped BO. Return -ENOENT when no bo_va is found, jumping to out_exec so the drm_exec context and GEM object reference are released. (cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68276", "url": "https://ubuntu.com/security/CVE-2026-68276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx: fix cleaner shader IB buffer overflow The cleaner shader sysfs path allocates a 16-dword (64 byte) IB but incorrectly fills (align_mask + 1) dwords. On GFX rings align_mask is 0xff, so the loop wrote 256 dwords into a 64-byte buffer, causing a kernel page fault. The IB only needs to be a minimal NOP shell to schedule the job; the cleaner shader itself is emitted on the ring via emit_cleaner_shader(). Fill 16 dwords to match the allocation. v2: Use ib_size_dw variable (Lijo) (cherry picked from commit bf21af331ebf72d0935fd70c73192414a422c03a)", "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-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-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-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-68282", "url": "https://ubuntu.com/security/CVE-2026-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: analogix_dp: Add missing error check for platform_get_resource() Add missing error check for platform_get_resource() return value to prevent NULL pointer dereference when memory resource is not available.", "cve_priority": "medium", "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-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-68292", "url": "https://ubuntu.com/security/CVE-2026-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues.", "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-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-68296", "url": "https://ubuntu.com/security/CVE-2026-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM Before commit 00d066a4d4ed (\"netdev_features: convert NETIF_F_LLTX to dev->lltx\"), NETIF_F_LLTX was set unconditionally in both __gre_tunnel_init() and ip6gre_tnl_init_features() alongside GRE_FEATURES: dev->features |= GRE_FEATURES | NETIF_F_LLTX; When that commit converted NETIF_F_LLTX to the dev->lltx flag, it placed 'dev->lltx = true' after the SEQ/CSUM early returns instead of before them. This causes GRE/GRETAP/ip6gre tunnels with SEQ or CSUM+encap to lose lockless TX, reintroducing _xmit_lock acquisition around their ndo_start_xmit. Since GRE xmit re-enters the stack via ip_tunnel_xmit(), holding _xmit_lock risks ABBA deadlock with the underlay device. CPU0 CPU1 ---- ---- lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); Fix by moving dev->lltx = true before the early returns in both functions, restoring the original unconditional behavior.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64575", "url": "https://ubuntu.com/security/CVE-2026-64575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: fix double sock release on batch realloc bpf_iter_tcp_batch() releases the current batch via bpf_iter_tcp_put_batch(), which drops the socket refs and rewrites each slot with the socket cookie, then grows the batch. cur_sk/end_sk are kept for bpf_iter_tcp_resume(), but on realloc failure the function returns ERR_PTR() before resume runs, leaving cur_sk < end_sk over slots that now hold cookies rather than sock pointers. bpf_iter_tcp_seq_stop() then calls bpf_iter_tcp_put_batch() again and dereferences a cookie as a struct sock. Empty the batch on the failure path so stop() does not release it again. The sockets were already freed by the first bpf_iter_tcp_put_batch(), so nothing leaks, and a later read() rescans the bucket from the start instead of skipping it. The sibling GFP_NOWAIT failure path still holds real socket references and is left for stop() to release. BUG: KASAN: null-ptr-deref in __sock_gen_cookie Read of size 8 at addr 0000000000000059 by task exploit ... __sock_gen_cookie (net/core/sock_diag.c:28) bpf_iter_tcp_put_batch (net/ipv4/tcp_ipv4.c:2918) bpf_iter_tcp_seq_stop (net/ipv4/tcp_ipv4.c:3270) bpf_seq_read (kernel/bpf/bpf_iter.c:205) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 entry_SYSCALL_64_after_hwframe Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68298", "url": "https://ubuntu.com/security/CVE-2026-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create() Commit 9e9787414882 (\"drm/xe/userptr: replace xe_hmm with gpusvm\") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a \"simple\" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). (cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4)", "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-68448", "url": "https://ubuntu.com/security/CVE-2026-68448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: check access to copy_file_range source with src mounter creds Commit 5dae222a5ff0c (\"vfs: allow copy_file_range to copy across devices\") allowed filesystems that implement the copy_file_range() f_op to decide if they want to access cross-sb copy from/to the same fs type. The same commit added checks to verify same sb copy for filesystems that implement ->copy_file_range() and do not support cross-sb copy at the time, namely, to ceph, fuse and nfs. The two remaining fs which implement ->copy_file_range(), cifs and overlayfs started to support cross-sb copy from this time. While overlayfs does support cross-sb copy when the two underlying files are on the same base fs, the copy operation on the two real files from two different overalyfs filesystems is performed with the mounter creds of the destination overlayfs and the read permission access hook for the source file was called with the wrong creds. This could cause either deny of access to copy which would otherwise be allowed (e.g. with splice) or allow read access to file which would otherwise be denied. Fix the latter case by explicitly verifying read access to source file with the source overlayfs mounter creds. The former case remains a quirk of cross-sb overlayfs copy, but userspace could fall back to regular copy so no harm done.", "cve_priority": "low", "cve_public_date": "2026-08-12 01:17: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-68307", "url": "https://ubuntu.com/security/CVE-2026-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix crash in reset link replay During reset recovery, mt7925_vif_connect_iter() replays firmware state for links tracked in mvif->valid_links. After MLO link changes or MCU timeout recovery, the driver bitmap can temporarily contain a link whose mac80211 bss_conf has already gone away. This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching the crash where x1, the second argument, is NULL: pc : mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] lr : mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] x2 : ffffff80a77f6018 x1 : 0000000000000000 x0 : ffffff8099402080 Call trace: mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common] Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA reset replay is unchanged because the helper still returns &vif->bss_conf for the legacy link.", "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-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-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-68311", "url": "https://ubuntu.com/security/CVE-2026-68311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: guard link STA in decap offload mt7925_sta_set_decap_offload() iterates over the vif valid_links mask when updating decap offload state for an MLO station. The station may not have a link STA for every valid link of the vif, so mt792x_sta_to_link() can return NULL for a link that belongs to the vif but not to the station. The function currently dereferences mlink before checking whether the link WCID is ready. If mlink is NULL, setting or clearing MT_WCID_FLAG_HDR_TRANS dereferences a NULL pointer. Skip links without a station link before touching mlink->wcid.", "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-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-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-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-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-68321", "url": "https://ubuntu.com/security/CVE-2026-68321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix FDIR filter leak on remove Perfect FDIR filters can be added while the interface is down and are kept on the software list for later restore. unregister_netdev() only calls ndo_stop when the device is up, so txgbe_fdir_filter_exit() in txgbe_close() is skipped in that case and the filters are leaked on driver remove. Free the filter list from txgbe_remove() as well.", "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-68330", "url": "https://ubuntu.com/security/CVE-2026-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix DMA direction for NPU mailbox buffer airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE, but some callers expect the NPU to write response data back into the same buffer: - airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into the buffer, then the caller reads it via memcpy() - airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back npu_stats_addr field in the response On non-cache-coherent architectures like EN7581 (Cortex-A53 without hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op — it does not invalidate the CPU cache. If the NPU-written cache line is still present in the CPU cache when the caller reads the buffer, the CPU observes stale data instead of the NPU response. This is a timing-sensitive bug: small mailbox buffers (~24 bytes) typically fit in a single cache line and may survive in the cache until the caller reads them, producing silent data corruption rather than a crash. The bug is more likely to trigger when the caller reads the response immediately after dma_unmap_single() without intervening cache-evicting operations. Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures dma_unmap_single() invalidates the CPU cache on non-coherent systems. The mailbox buffers are small so there is no performance concern.", "cve_priority": "low", "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-68332", "url": "https://ubuntu.com/security/CVE-2026-68332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix potential use-after-free in airoha_ppe_deinit() airoha_ppe_deinit() replaces the NPU pointer with NULL via rcu_replace_pointer() but does not wait for existing RCU readers to exit before calling ppe_deinit() and airoha_npu_put(). This can cause a use-after-free if a reader in an RCU read-side critical section still holds a reference to the NPU when it is freed. The init path (airoha_ppe_init) already calls synchronize_rcu() after rcu_assign_pointer(), but the deinit path introduced in commit 6abcf751bc08 (\"net: airoha: Fix schedule while atomic in airoha_ppe_deinit()\") omitted the matching barrier when switching from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer(). Add synchronize_rcu() before ppe_deinit() to ensure all existing RCU readers have completed before the NPU resources are released.", "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-68334", "url": "https://ubuntu.com/security/CVE-2026-68334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix io_thread race in rxrpc_wake_up_io_thread() rxrpc_wake_up_io_thread() checks local->io_thread before waking it, but then reloads the pointer for wake_up_process(). local->io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so the second load can see NULL even if the first load did not. Take a READ_ONCE() snapshot and use it for both the NULL check and the wake_up_process() call, as rxrpc_encap_rcv() already does.", "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-68341", "url": "https://ubuntu.com/security/CVE-2026-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix use after free in unlock_ovpn() unlock_ovpn() iterates over the release_list using llist_for_each_entry() and drops the peer reference inside the loop body via ovpn_peer_put(). If this drops the last reference, the peer is eventually freed. However, llist_for_each_entry() reads peer->release_entry.next in the loop advance expression, which runs after the body. By that time the peer may have already been freed, resulting in a use after free when advancing to the next list entry. Fix this by using llist_for_each_entry_safe(), which caches the next pointer before executing the loop body.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68342", "url": "https://ubuntu.com/security/CVE-2026-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: avoid putting unrelated P2P peer on socket release ovpn_peer_release_p2p() is called when an OVPN UDP socket is being destroyed. It checks the currently published P2P peer and releases it only if that peer still uses the socket being destroyed. A peer replacement can publish a new peer before the old UDP socket is destroyed. When the old socket destruction path runs afterwards, ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the new peer uses a different socket, the function takes the socket mismatch branch. That branch still calls ovpn_peer_put(peer). At this point, however, peer is the currently published replacement peer, not the peer associated with the socket being destroyed. Dropping its reference can free it while ovpn->peer still points to it, leading to later use-after-free accesses from the peer and socket cleanup paths. KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer object. In the reproducer, the object is allocated from ovpn_peer_new() via ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU callback processing. Observed access sites include ovpn_peer_remove(), ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn(). Fix this by returning from the socket mismatch branch without putting the peer.", "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-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-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-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-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-68356", "url": "https://ubuntu.com/security/CVE-2026-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: airoha: Prevent division by zero when clock frequency is zero clk_get_rate() can return 0 when the clock provider is not properly configured or the clock is unmanaged. The driver uses wdt_freq as a divisor directly in airoha_wdt_probe() to compute max_timeout and in airoha_wdt_get_timeleft() to compute the remaining time, which results in a division by zero. Add a check for wdt_freq == 0 in probe and return -EINVAL with dev_err_probe() to prevent the division by zero and provide a diagnostic message.", "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-68358", "url": "https://ubuntu.com/security/CVE-2026-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-kraken3) 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-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-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-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-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-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-68374", "url": "https://ubuntu.com/security/CVE-2026-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: sysfs: add lock to bos_descriptors_read() Add a lock to the function bos_descriptors_read(). This function accesses udev->bos, which could be simultaneously freed in usb_reset_and_verify_device(), a function that is commonly called in drivers all over the kernel.", "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-68378", "url": "https://ubuntu.com/security/CVE-2026-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions: - A pin is registered with two or more dpll devices (dpll_A, dpll_B) - The pin has ref_sync pairs with other pins - During unregistration of dpll_A's pins, a ref_sync partner pin is unregistered first, removing it from dpll_A->pin_refs - But since the partner pin is still registered with dpll_B, its dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT run and the partner stays in the pin's ref_sync_pins xarray - When the pin itself is then unregistered from dpll_A, the delete notification calls dpll_msg_add_pin_ref_sync() which finds the partner in ref_sync_pins, passes dpll_pin_available() (partner is still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A, partner) returns NULL because partner was already removed from dpll_A->pin_refs - The NULL priv pointer is passed to the driver's ref_sync_get callback, which dereferences it BUG: kernel NULL pointer dereference, address: 0000000000000034 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x] Call Trace: dpll_msg_add_pin_ref_sync+0xb8/0x200 dpll_cmd_pin_get_one+0x3b6/0x4b0 dpll_pin_event_send+0x72/0x140 __dpll_pin_unregister+0x5a/0x2b0 dpll_pin_unregister+0x49/0x70 Fix this by skipping ref_sync pins whose priv pointer cannot be resolved for the current dpll device.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68379", "url": "https://ubuntu.com/security/CVE-2026-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix TIME_WAIT socket reference leak on PSP policy failure Release the TIME_WAIT socket reference and jump to discard_it upon PSP policy failure in both IPv4 and IPv6 receive paths. This prevents a memory leak of tcp_tw_bucket structures.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68380", "url": "https://ubuntu.com/security/CVE-2026-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix use-after-free of mm_struct in job scheduler amdxdna_cmd_submit() stores current->mm in job->mm without holding any reference. aie2_sched_job_run() later access job->mm from the DRM scheduler worker thread. With only a raw pointer and no structural reference, the mm_struct can be freed before the scheduler runs the job. Fix this by calling mmgrab() to hold a structural mm_count reference for the lifetime of the job, paired with mmdrop() in every cleanup path.", "cve_priority": "high", "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-68384", "url": "https://ubuntu.com/security/CVE-2026-68384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits. - Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it. While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one. (cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68385", "url": "https://ubuntu.com/security/CVE-2026-68385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/checksum: Fix csum_partial() without vector facility Currently csum_partial() calls csum_copy() with copy=false and dst=NULL. On machines without the vector facility, csum_copy() falls back to cksm(dst, ...), causing the checksum to be calculated from address zero instead of the source buffer. The VX implementation already checksums data loaded from src. Make the fallback do the same by passing src to cksm().", "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-68387", "url": "https://ubuntu.com/security/CVE-2026-68387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: add locking for raw flags bitfield With commit 890e5198a6e5 (\"can: raw: use bitfields to store flags in struct raw_sock\") the formerly separate integer values have been integrated into a single bitfield. This led to a read-modify-write operation when changing a flag in raw_setsockopt() which now needs a locking to prevent concurrent access. Instead of adding a lock/unlock hell in each of the flag manipulations this patch introduces a wrapper for a new raw_setsockopt_locked() function analogue to the isotp_setsockopt[_locked]() approach in net/can/isotp.c [mkl: use Closes tag instead of Link]", "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-68393", "url": "https://ubuntu.com/security/CVE-2026-68393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: extend conn_hash lookup critical sections Using RCU-protected pointers outside the critical sections without refcount is incorrect and may result to UAF. Extend critical section to cover both hci_conn_hash lookup and use of the returned conn. Add surrounding rcu_read_lock() also when return value is not used, in preparation for RCU lockdep requirement to hci_lookup_le_connect(). This avoids concurrent deletion of the conn before we are done dereferencing it. Also, make sure to hold hdev->lock when accessing hdev->accept_list.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68394", "url": "https://ubuntu.com/security/CVE-2026-68394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update MGMT_OP_LOAD_CONN_PARAM queues conn_update_sync() when a single parameter update changes an existing LE central connection. The queued work currently stores a borrowed hci_conn_params entry from hdev->le_conn_params. A later LOAD_CONN_PARAM request can clear disabled parameters and free that entry before hci_cmd_sync_work() runs the queued callback. Do not keep the borrowed hci_conn_params pointer in queued work. Queue the hci_conn instead and hold a reference until the queued callback completes. When the work runs, revalidate that the connection is still present, look up the current hci_conn_params entry, and cancel the update if userspace removed that entry while the work was pending. Copy the interval values from the current params entry under hdev->lock, then drop the lock and keep using hci_le_conn_update_sync() to issue the update. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in conn_update_sync+0x2a/0xf0 [bluetooth] Read of size 1 at addr ffff88810c697126 by task kworker/u17:0/377 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 kasan_report+0xe0/0x110 conn_update_sync+0x2a/0xf0 [bluetooth] hci_cmd_sync_work+0x187/0x210 [bluetooth] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 Allocated by task 466: hci_conn_params_add+0xa6/0x240 [bluetooth] load_conn_param+0x4e1/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] Freed by task 474: kfree+0x313/0x590 hci_conn_params_clear_disabled+0x9b/0xc0 [bluetooth] load_conn_param+0x4bf/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth]", "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-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-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-68400", "url": "https://ubuntu.com/security/CVE-2026-68400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint memory access array and to comply with the FF-A spec instead of defaulting to `sizeof(struct ffa_mem_region)`. This requires moving `ffa_mem_region_additional_setup()` earlier in the setup flow. Also, add sanity checks to ensure the calculated descriptor offsets do not exceed `max_fragsize`.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68401", "url": "https://ubuntu.com/security/CVE-2026-68401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() Sashiko (locally) reports multiple out-of-bound issues in ffa_setup_and_transmit: 1) Writing ep_mem_access->reserved can write out of bounds for FFA versions < 1.2 as ffa_emad_size_get() returns 16 bytes in that case while reserved has an offset of 24. Instead of zeroing fields, memset the struct to zero first based on the FFA version. 2) Make sure there is enough size to write constituents. While at it, convert the only sizeof() in the driver that uses a type instead of variable.", "cve_priority": "high", "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-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-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-68409", "url": "https://ubuntu.com/security/CVE-2026-68409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: defer link RX stats percpu free to RCU sta_remove_link() frees a removed MLO link's RX stats percpu buffer right away, but defers only the link container to RCU: \tsta_info_free_link(&alloc->info); \tkfree_rcu(alloc, rcu_head); The RX fast path reads link_sta under rcu_read_lock and writes the percpu stats. A reader that resolved link_sta before the removal keeps the pointer. The container stays alive from the kfree_rcu, so the read still works. But the percpu block it points to is already freed. This needs uses_rss. That is when pcpu_rx_stats exists. The full STA teardown frees the deflink stats only after synchronize_net(). The link removal path had no such barrier. The race is hard to win in practice, but the free should still wait for RCU. Free the link together with its data from a single RCU callback, so the percpu block is reclaimed only after readers drain.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20: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-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-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-68412", "url": "https://ubuntu.com/security/CVE-2026-68412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan() If the test against IEEE80211_MAX_SSID_LEN fails, then 'creq' leaks. Use the existing error handling path to fix it.", "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-64566", "url": "https://ubuntu.com/security/CVE-2026-64566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags() When iptfs_skb_add_frags() copies frag references from the source frag walk into a new SKB, it increments the page reference count via __skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the destination SKB's skb_shinfo->flags. If the source SKB carries shared frags (e.g. from a page-pool backed receive path), the new inner SKB will appear to ESP as having privately owned frags. A subsequent esp_input() call for a nested transport-mode SA then takes the no-COW fast path and decrypts in place, writing over pages that are still referenced by the outer IPTFS SKB. This causes kernel-visible memory corruption and can trigger a panic. All other frag-transfer helpers in the kernel (skb_try_coalesce, skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this convention by setting the flag inside the loop immediately after __skb_frag_ref() and nr_frags++, so every exit path that attaches a frag unconditionally propagates SKBFL_SHARED_FRAG.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68415", "url": "https://ubuntu.com/security/CVE-2026-68415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear mode callbacks after failed mode setup xfrm_state_gc_task can run long after a failed IPTFS state setup. In the reproduced case, __xfrm_init_state() cached x->mode_cbs, IPTFS setup returned -ENOMEM before publishing mode_data, and the temporary module reference from xfrm_get_mode_cbs() was dropped immediately. The dead state then kept x->mode_cbs until deferred GC ran after xfrm_iptfs had been unloaded. Clear x->mode_cbs when mode init or clone fails before publishing mode_data. Those states never installed mode-specific state or the long-term IPTFS module pin, so deferred GC has nothing mode-specific to destroy and must not retain a callback table pointer past the temporary lookup reference. The buggy scenario involves two paths, with each column showing the order within that path: failed setup path: 1. cache x->mode_cbs 2. mode setup fails before mode_data 3. drop the temporary module ref 4. dead state keeps x->mode_cbs cached GC/unload path: 1. xfrm_state_put() queues GC work 2. xfrm_iptfs unloads later 3. xfrm_state_gc_task runs 4. GC dereferences stale x->mode_cbs This also covers the failed clone path where clone_state() returns before publishing mode_data. Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y failslab_stacktrace_filter matched xfrm_iptfs frames ack_error=-12 FAULT_INJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrm_state_gc_task RIP: xfrm_state_gc_task+0x142/0x650 Modules linked in: esp4_offload xfrm_user [last unloaded: xfrm_iptfs] Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68418", "url": "https://ubuntu.com/security/CVE-2026-68418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent user-triggered null deref on QP create Previously, the user QP creation path would only attempt to populate iwqp->iwpbl if the user-provided req.user_wqe_bufs field was non-zero. The problem is that iwqp->iwpbl is unconditionally dereferenced later on in irdma_setup_virt_qp. While there was a check for iwqp->iwpbl != NULL, this check would only occur if req.user_wqe_bufs was non-zero. The end result is that a user could send a zero user_wqe_bufs value and trigger a null ptr deref. Fix this by unconditionally calling irdma_get_pbl and bailing if it fails, similar to the CQ and SRQ paths.", "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-68420", "url": "https://ubuntu.com/security/CVE-2026-68420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: reject optional IPTFS templates in outbound policies syzbot reported a stack-out-of-bounds read in xfrm_state_find() which flows from xfrm_tmpl_resolve_one(). Commit 3d776e31c841 (\"xfrm: Reject optional tunnel/BEET mode templates in outbound policies\") disallowed optional tunnel and BEET in outbound policies to prevent this. Later when IPTFS added, it was not covered by that fix and can still trigger the out-of-bounds read; Extend the check to disallow optional IPTFS in outbound policies as well. IPTFS should be identical to tunnel mode. IN and FWD policies are not affected: xfrm_tmpl_resolve_one() is only reachable via the outbound path. Reproducer, before: ip link add dummy0 type dummy ip link set dummy0 up ip addr add 10.1.1.1/24 dev dummy0 ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 mode transport ping -W 1 -c 1 10.1.1.2 PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data. [ 64.168420] ================================================================== [ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844 [ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full) [ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 64.169977] Call Trace: [ 64.169977] [ 64.169977] dump_stack_lvl+0x47/0x70 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] print_report+0x152/0x4b0 [ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0 [ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20 [ 64.169977] ? __virt_addr_valid+0x21b/0x230 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] kasan_report+0xa8/0xd0 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm_dst_hash+0x24/0xc0 [ 64.169977] xfrm_state_find+0xa2d/0x2f90 [ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570 [ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10 [ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 64.169977] ? kernel_text_address+0x5b/0x80 [ 64.169977] ? __kernel_text_address+0xe/0x30 [ 64.169977] ? unwind_get_return_address+0x5e/0x90 [ 64.169977] ? arch_stack_walk+0x8c/0xe0 [ 64.169977] xfrm_tmpl_resolve+0x130/0x200 [ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10 [ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110 [ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10 [ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310 [ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80 [ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10 [ 64.169977] ? ip_route_output_key_hash+0xc6/0x110 [ 64.169977] ? kasan_save_track+0x10/0x30 [ 64.169977] xfrm_lookup_route+0x18/0xe0 [ 64.169977] ip4_datagram_release_cb+0x4c9/0x530 [ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10 [ 64.169977] ? do_raw_spin_lock+0x71/0xc0 [ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 64.169977] release_sock+0xb0/0x170 [ 64.169977] udp_connect+0x43/0x50 [ 64.169977] __sys_connect+0xa6/0x100 [ 64.169977] ? alloc_fd+0x2e9/0x300 [ 64.169977] ? __pfx___sys_connect+0x10/0x10 [ 64.169977] ? preempt_latency ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68421", "url": "https://ubuntu.com/security/CVE-2026-68421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx() put_prev_task_scx() warns when a runnable task drops to a lower sched_class without SCX_OPS_ENQ_LAST, on the assumption that balance_one() would have kept it running. Core scheduling breaks that: a forced-idle SMT sibling reschedules through the core_pick fast path in pick_next_task(), which skips pick_task_scx() and thus balance_one(), so a runnable task can drop to idle with ENQ_LAST unset. Gate the warning on sched_cpu_cookie_match(): a cookie mismatch means core scheduling forced the idle, while a match (or core scheduling off) still catches a genuine missing-ENQ_LAST drop.", "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-68426", "url": "https://ubuntu.com/security/CVE-2026-68426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix stale skb->prev after async crypto steals a GSO segment skb_gso_segment() leaves the segment list head with ->prev pointing at the last segment, an invariant validate_xmit_skb_list() relies on when it sets its tail pointer (tail = skb->prev). When validate_xmit_xfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validate_xmit_skb_list() later does tail->next = skb, writing through that stale pointer -- a use-after-free. Repoint skb->prev at the last retained segment before returning.", "cve_priority": "critical", "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-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-2023-20585", "url": "https://ubuntu.com/security/CVE-2023-20585", "cve_description": "Insufficient checks of the RMP on host buffer access in IOMMU may allow an attacker with privileges and a compromised hypervisor to trigger an out of bounds condition without RMP checks, resulting in a potential loss of confidential guest integrity.", "cve_priority": "low", "cve_public_date": "2026-04-16 19:16:00 UTC" }, { "cve": "CVE-2026-68364", "url": "https://ubuntu.com/security/CVE-2026-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix ISM dc_lock deadlock during suspend [Why] System hang observed during suspend/resume while video is playing. amdgpu_dm_ism_disable() is called under dc_lock and waits for ISM delayed work via disable_delayed_work_sync(). The work handlers themselves take dc_lock, producing an ABBA deadlock when a worker is in flight at suspend time. [How] Split the disable path into two phases with opposite locking contracts: 1. amdgpu_dm_ism_disable() -- quiesces workers, must NOT hold dc_lock. 2. amdgpu_dm_ism_force_full_power() (new) -- drives the ISM FSM back to FULL_POWER_RUNNING, must hold dc_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72064", "url": "https://ubuntu.com/security/CVE-2026-72064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Sync page pool RX frags for CPU MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack.", "cve_priority": "medium", "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-72098", "url": "https://ubuntu.com/security/CVE-2026-72098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: fix buffer overflow in FEC calculation There's a buffer overflow in dm-verity-fec: if (neras && *neras <= v->fec->roots) \tfio->erasures[(*neras)++] = i; This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72248", "url": "https://ubuntu.com/security/CVE-2026-72248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: support IPIP tunnel with direct xmit The combination of IPIP tunnel with direct xmit, eg. bridge device, breaks because no dst_entry is provided to check the skb headroom and to set the iph->frag_off field. This leads to invalid dst usage and can trigger a crash in the tunnel transmit path. Fix this by moving dst_cache and dst_cookie out of the runtime union so that they can be shared by neighbour, xfrm, and direct tunnel flows. For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve route state in these shared fields and release it through the common dst release path. Since dst_entry is now available to the three supported xmit modes and dst_release() already deals with NULL dst, remove the xmit type check in nft_flow_dst_release(). Moreover, skip the check if the dst entry is NULL in nf_flow_dst_check() which is now the case for the direct xmit case. Based on patch from Rein Wei .", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72249", "url": "https://ubuntu.com/security/CVE-2026-72249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: use dst in this direction when pushing IPIP header When pushing the IPIP header, the route of the other direction is used to calculate the headroom, use the route in this direction. Accessing the other tuple to set the IP source and destination is fine because this tuple does not provide such information to avoid storing redundant information. However, this tuple already provides the dst for this direction, this went unnoticed because this bug affects headroom and iph->frag_off only at this stage.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72287", "url": "https://ubuntu.com/security/CVE-2026-72287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the \"normal\" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a \"late\" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72329", "url": "https://ubuntu.com/security/CVE-2026-72329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/liquidio: drop cached VF pci_dev LUT The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST. Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72355", "url": "https://ubuntu.com/security/CVE-2026-72355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix barriering when walking subrequest list Fix the barriering used when walking the subrequest list in retry as there's a possibility of seeing a subreq that's just been added by the application thread.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72412", "url": "https://ubuntu.com/security/CVE-2026-72412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/mm: Fix handling of _PAGE_UNUSED pte bit The _PAGE_UNUSED softbit should not really be lying around. Its sole purpose is to signal to try_to_unmap_one() and try_to_migrate_one() that the page can be discarded instead of being moved / swapped. KVM has no way to know why a page is being unmapped, so it sets the bit on userspace ptes corresponding to unused guest pages every time they get unmapped. KVM has no reasonable way to clear the bit once the page is in use again. While set_ptes() checks and clears the bit, other paths that set new ptes did not. This led to used pages being thrown out as if they were unused, causing guest corruption. Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in set_pte(), i.e. whenever a present pte is getting set. The check in set_ptes() is then redundant and can be removed. Also fix gmap_helper_try_set_pte_unused() to only set the bit if the pte is present; the _PAGE_UNUSED bit is only defined for present ptes and thus should not be set for non-present ptes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72417", "url": "https://ubuntu.com/security/CVE-2026-72417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto() Add sanity check for iph->ihl field in nf_flow_ip4_tunnel_proto() before using it to compute the header size, avoiding out-of-bounds access with malformed IP headers. While at it, use iph->protocol instead of the hardcoded IPPROTO_IPIP constant when setting ctx->tun.proto and reference ctx->tun.hdr_size when updating ctx->offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72442", "url": "https://ubuntu.com/security/CVE-2026-72442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: fix and simplify IP6IP6 tunnel handling Fix nf_flow_ip6_tunnel_proto() to use pskb_may_pull() instead of skb_header_pointer() to ensure the outer IPv6 header is in the skb headroom, which is required for subsequent packet processing. Move ctx->offset update inside the IPPROTO_IPV6 conditional block since it should only be adjusted when an IP6IP6 tunnel is actually detected. Simplify the rx path by removing ipv6_skip_exthdr() and checking ip6h->nexthdr directly, as the flowtable fast path only handles simple IP6IP6 encapsulation without extension headers. Drop the tunnel encapsulation limit destination option support from the tx path to match, since the rx path no longer handles extension headers. Remove the encap_limit parameter from nf_flow_offload_ipv6_forward(), nf_flow_tunnel_ip6ip6_push() and nf_flow_tunnel_v6_push(), along with the ipv6_tel_txoption struct and related headroom/MTU adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72463", "url": "https://ubuntu.com/security/CVE-2026-72463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix dev use-after-free in xfrm async resumption xfrm async resumption hold skb->dev refcnt until after transport_finish. However, xfrm_rcv_cb may modify skb->dev to tunnel dev without taking device reference, such as vti_rcv_cb. The subsequent async resumption will decrement the tunnel device's reference count, which lead to uaf of tunnel dev and refcnt leak of orig dev as below: unregister_netdevice: waiting for vti1 to become free. Usage count = -2 Stash the original skb->dev to fix refcnt imbalance. The new skb->dev set by xfrm_rcv_cb can race with device teardown. Extend rcu protection over xfrm_rcv_cb and transport_finish to prevent races.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72477", "url": "https://ubuntu.com/security/CVE-2026-72477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: call _ntfs_bad_inode() when failing to rename It is safe to call _ntfs_bad_inode on live inodes since: commit 519b078998ce (\"fs/ntfs3: Exclude call make_bad_inode for live nodes.\") The WARN_ON was added when it wasn't safe by: commit d99208b91933 (\"fs/ntfs3: cancle set bad inode after removing name fails\") Replace the WARN_ON with a call to _ntfs_bad_inode() to prevent further operations on the inconsistent inode.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72493", "url": "https://ubuntu.com/security/CVE-2026-72493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: serialize netif_running() check in enqueue_to_backlog() Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup(). The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit). Commit e9e4dd3267d0 (\"net: do not process device backlog during unregistration\") introduced a lockless netif_running() check in enqueue_to_backlog() to prevent queuing packets to an unregistering device. However, this creates a TOCTOU race window. A lockless transmitter (like veth_xmit) can pass the check before dev_close() clears IFF_UP. If the transmitter is then delayed, flush_all_backlogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed. Fix this by moving the netif_running() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netif_running() after the flush/close completes (so it gets dropped).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72494", "url": "https://ubuntu.com/security/CVE-2026-72494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Replace waitqueue and flag with completion The driver previously used a waitqueue along with an explicit request_done flag, but without proper barriers around request_done. An earlier patch by Gui-Dong Han attempted to fix this by adding the missing memory barriers. Rather than adding the barriers, this patch replaces the waitqueue+flag with a completion, which is designed for this exact purpose.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72496", "url": "https://ubuntu.com/security/CVE-2026-72496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Proper rollback if the ioremap fails bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74269", "url": "https://ubuntu.com/security/CVE-2026-74269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt: fix head underflow on XDP head-grow The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free. The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with this commit applied causes the test to run successfully to completion. The other rx_skb_func implementations don't have this issue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74350", "url": "https://ubuntu.com/security/CVE-2026-74350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate fast symlink target during inode read ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment. A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer. Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated. This keeps malformed fast symlinks from reaching the read path. Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x19f/0x330 (?:?) kasan_report+0xe0/0x110 (?:?) kasan_check_range+0x105/0x1b0 (?:?) __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72495", "url": "https://ubuntu.com/security/CVE-2026-72495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid repeated requests to allocate WC pages Applications can request multiple WC pages for the same ucontext. As of now, only 1 WC page per ucontext is supported. Add a lock to avoid concurrent access and a check to fail repeated requests. Also, if the mmap entry insert fails for the WC, free the Doorbell page index mapped for the WC page.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72501", "url": "https://ubuntu.com/security/CVE-2026-72501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Initialize dpi variable to zero dpi is initialized only for BNXT_RE_ALLOC_WC_PAGE, but copied for all the cases. So initialize the dpi to 0.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72278", "url": "https://ubuntu.com/security/CVE-2026-72278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Re-translate VNCR before injecting abort KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor updates and MMU faults.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68083", "url": "https://ubuntu.com/security/CVE-2026-68083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix path resolution in ksmbd_vfs_kern_path_create The SMB2 open lookup is rooted at the share with LOOKUP_BENEATH, but the create/mkdir/hardlink sink is not: ksmbd_vfs_kern_path_create() builds an absolute path with convert_to_unix_name() and resolves it from AT_FDCWD via start_creating_path(), so a \"..\" component is walked from the real filesystem root and escapes the export. An authenticated client races a missing path component so the rooted open lookup returns -ENOENT (taking the create branch) while the same component is present (a directory) when the create walk runs; the create then resolves \"..\" out of the share. Root the create walk at the share like the lookup and rename paths already are: resolve the parent with vfs_path_parent_lookup(..., LOOKUP_BENEATH, &share_conf->vfs_path) and create the final component with start_creating_noperm(). convert_to_unix_name() then has no callers and is removed.", "cve_priority": "high", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-68457", "url": "https://ubuntu.com/security/CVE-2026-68457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use opener credentials for FSCTL mutations SET_SPARSE, SET_ZERO_DATA and SET_COMPRESSION operate on an open SMB handle but call VFS xattr, fallocate or fileattr helpers with the current ksmbd worker credentials. Those helpers can revalidate inode permissions, ownership and LSM policy independently of the SMB handle access mask. Run each operation with the credentials captured in the target file when the handle was opened. Keep credential handling local to these single-file FSCTLs rather than applying session credentials to the complete IOCTL handler, which also contains handle-less and multi-handle operations.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72041", "url": "https://ubuntu.com/security/CVE-2026-72041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: use sk_msg_free_partial to fix partial send sk_msg_free_partial() ensures consistency of the skmsg at every iteration, without having to manually handle uncharges and offsets. This simplifies the code, and fixes some bugs in skmsg accounting when we don't send the full contents.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72046", "url": "https://ubuntu.com/security/CVE-2026-72046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing.", "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-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21: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-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72137", "url": "https://ubuntu.com/security/CVE-2026-72137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: nat_keepalive: avoid double free on send error nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6 send helper reports an error. That cleanup is only correct before the skb is handed to the output path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the networking stack may already have consumed the skb before returning an error, so freeing it again is unsafe. Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4() and nat_keepalive_send_ipv6(), where the caller still owns the skb, and keep nat_keepalive_send() responsible only for family dispatch and the unsupported-family cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72139", "url": "https://ubuntu.com/security/CVE-2026-72139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: defer md5sig_info kfree past RCU grace period in tcp_connect The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: \tif (needs_md5) { \t\ttcp_ao_destroy_sock(sk, false); \t} else if (needs_ao) { \t\ttcp_clear_md5_list(sk); \t\tkfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); \t} Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with tcp-diag]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72191", "url": "https://ubuntu.com/security/CVE-2026-72191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: validate split-point offset in indx_insert_into_buffer indx_insert_into_buffer() computes used = used1 - to_copy - sp_size; memmove(de_t, Add2Ptr(sp, sp_size), used - le32_to_cpu(hdr1->de_off)); where sp and sp_size come from hdr_find_split(). hdr_find_split() walks entries by le16_to_cpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFS_DE). index_hdr_check(), the on-load gatekeeper, only validates header-level fields (used, total, de_off) and does not walk per-entry sizes. A crafted NTFS image whose leaf INDEX_HDR reports used == total but contains one interior NTFS_DE with size = 0xFFF0 therefore passes validation, descends to indx_insert_into_buffer() through the ntfs_create() -> indx_insert_entry() path, and makes hdr_find_split() return an sp whose sp_size (0xFFF0) greatly exceeds the remaining bytes in the buffer. The u32 subtraction underflows and the memmove count becomes a near-4-GiB value, producing an out-of-bounds kernel write that corrupts adjacent allocations and panics the kernel. Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a single 'touch' inside the mounted directory; crash site resolves to fs/ntfs3/index.c at the memmove. Trigger requires only local mount of an attacker-supplied filesystem image (USB, loopback, or removable media auto-mount). Reject the split whenever the chosen sp plus its declared size already extends past hdr1->used. This is the minimal fix; it preserves the existing hdr_find_split() contract and relies on the same out: cleanup path as the pre-existing error returns. A prior OOB read in the very same indx_insert_into_buffer() memmove was fixed in commit b8c44949044e (\"fs/ntfs3: Fix OOB read in indx_insert_into_buffer\") by tightening hdr_find_e(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdr_find_split(), not hdr_find_e(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72217", "url": "https://ubuntu.com/security/CVE-2026-72217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing xdr_buf_to_bvec() writes a bio_vec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it. rq_bvec, the array passed by nfsd_vfs_write(), is allocated to exactly rq_maxpages entries with no slack. The OOB store can land in adjacent slab memory; the bv_len and bv_offset fields written there are derived from client-supplied RPC payload sizes. Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72220", "url": "https://ubuntu.com/security/CVE-2026-72220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp->rq_procinfo->pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72221", "url": "https://ubuntu.com/security/CVE-2026-72221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: wait for in-flight TLS handshake callback when cancel loses race When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed. The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result. If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue. If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed. Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed to fire because handshake_complete() invokes svc_tcp_handshake_done() unconditionally once it has set HANDSHAKE_F_REQ_COMPLETED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72222", "url": "https://ubuntu.com/security/CVE-2026-72222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: pin svc_xprt across the asynchronous TLS handshake callback svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of(). Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done. The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry. Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all(). [cel: rewrote commit message to describe the actual change]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72277", "url": "https://ubuntu.com/security/CVE-2026-72277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the simpler thing for now and just reject everything that isn't memory.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72279", "url": "https://ubuntu.com/security/CVE-2026-72279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR KVM currently maps the L1 VNCR into the host stage-1 by relying entirely on the permissions of the guest stage-1. At the same time, it is entirely possible that the backing PFN is read-only (e.g. RO memslot), meaning that the L1 VNCR should use at most a read-only mapping. Cache the writability of the PFN in the VNCR TLB and use it to constrain the resulting fixmap permissions. Promote VNCR permission faults to an SEA in the case where the guest attempts to write to a read-only endpoint. Conveniently, this also plugs a page leak found by Sashiko [*] resulting from the early return for a read-only PFN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72288", "url": "https://ubuntu.com/security/CVE-2026-72288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling Hyunwoo Kim reports some really bad races should the following situation occur: - LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C If the last two race nicely enough, vgic_prune_ap_list() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows. The fix is two-fold: - Before dropping the irq and ap_list locks, take a reference on the irq - Do not try to handle migration of the pending bit: there is no expectation that this state is retained, as per the architecture With that, we're sure that the interrupt is still around, and we safely remove it from the AP list as it has no target at this stage (unless another interrupt fires, but that's another story).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "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-72317", "url": "https://ubuntu.com/security/CVE-2026-72317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: pin upper rpc_clnt across the TLS connect_worker The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt. The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported. Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one. The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72318", "url": "https://ubuntu.com/security/CVE-2026-72318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate DFS referral string offsets parse_dfs_referrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server. Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative max_len is then passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds. Validate each string offset before deriving the string pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72320", "url": "https://ubuntu.com/security/CVE-2026-72320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_lookup: fix catchall element handling with inverted lookups nft_lookup_eval() decides whether a lookup matched (`found`) from the direct set lookup and priv->invert before falling back to the catchall element used by interval sets (e.g. nft_set_rbtree) for the open-ended default range. Since `found` is never recomputed after `ext` is replaced by the catchall lookup, inverted lookups (NFT_LOOKUP_F_INV, \"!= @set\") can wrongly match or wrongly skip the catchall element, producing the wrong verdict. Fold the catchall lookup into `ext` before computing `found`, matching the order already used by nft_objref_map_eval().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72366", "url": "https://ubuntu.com/security/CVE-2026-72366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_create_write_req() to handle async cache object creation netfs_create_write_req() will skip caching if the fscache cookie is disabled, but this is a problem because async cache object creation might not have got far enough yet that has been enabled - thereby causing the call to fscache_begin_write_operation() to be skipped. Fix this by removing the checks on the cookie and delegating this to fscache_begin_write_operation().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72381", "url": "https://ubuntu.com/security/CVE-2026-72381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of fp->owner.name in durable handle owner check Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d (\"ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd\") made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized. BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8 Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72393", "url": "https://ubuntu.com/security/CVE-2026-72393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: don't cache shinfo across skb realloc fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb including the shared info. We can't use the pointer calculated before the call. BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0 Read of size 4 at addr ff110000262edd98 by task swapper/5/0 Call Trace: fbnic_tx_lso.isra.0+0x668/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 Allocated by task 8653: __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xcc/0x6c0 sock_alloc_send_pskb+0x327/0x3f0 __ip_append_data+0x188b/0x47a0 ip_make_skb+0x24a/0x300 udp_sendmsg+0x14d2/0x21e0 Freed by task 0: kfree+0x123/0x5a0 pskb_expand_head+0x36c/0xfa0 fbnic_tx_lso.isra.0+0x500/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 sch_direct_xmit+0x25b/0x1100 The buggy address belongs to the object at ff110000262edc40 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 344 bytes inside of freed 640-byte region [ff110000262edc40, ff110000262ede", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72398", "url": "https://ubuntu.com/security/CVE-2026-72398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: add INIT verification after cookie unpacking In SCTP handshake, the INIT chunk is initially processed by the server and embedded into the cookie carried in INIT-ACK. The client then returns this cookie via COOKIE-ECHO, where the server unpacks it and reconstructs the original INIT chunk. When cookie authentication is enabled, the cookie contents are protected against tampering, so reusing the unpacked INIT without re-verification is safe. However, when cookie authentication is disabled, the reconstructed INIT can no longer be trusted. In this case, the INIT must be explicitly validated after unpacking to avoid processing potentially tampered data. Add sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO processing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook()) when cookie_auth_enable is disabled. On failure, the new association is freed and the packet is discarded. Also tighten cookie validation in sctp_unpack_cookie() by verifying the embedded chunk type is SCTP_CID_INIT before treating it as an INIT chunk. Finally, update sctp_verify_init() to validate parameter bounds using the actual embedded INIT length instead of chunk->chunk_end, since the INIT stored in COOKIE-ECHO may not span the entire chunk buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72399", "url": "https://ubuntu.com/security/CVE-2026-72399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: check the number of BDs needed for xdp_frame The size of xdp_redirect_arr array is ENETC_MAX_SKB_FRAGS. However, the number of fragments contained in xdp_frame may be greater than or equal to ENETC_MAX_SKB_FRAGS, which will cause the access to xdp_redirect_arr to be out of bounds.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72429", "url": "https://ubuntu.com/security/CVE-2026-72429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix type confusion of dst_entry IOAM uses a dummy dst_entry(null_dst) to mark that the destination should not be changed after the transformation. This dst is stored in the IOAM lwt state and may be passed to dst_cache_set_ip6(). However, the IPv6 dst cache path eventually calls rt6_get_cookie(), which treats the dst_entry as part of a struct rt6_info. Since the null_dst was embedded directly as a struct dst_entry in struct ioam6_lwt, this resulted in an invalid cast and rt6_get_cookie() reading fields from the wrong object. In practice, the wrong cookie is not used while dst->obsolete is zero, but rt6_get_cookie() may also access per-cpu value when rt->sernum is zero. In this case, rt->sernum aliases ioam6_lwt::cache::reset_ts, which can become zero, making this a potential invalid pointer access. Fix this by embedding a full struct rt6_info for the dummy IPv6 route and passing its dst member to the dst APIs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72436", "url": "https://ubuntu.com/security/CVE-2026-72436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash types Sashiko pointed out that there are a few lockless RCU readers using test_bit() which is a relaxed atomic operation and provides no memory barrier guarantees. Use test_bit_acquire() instead where the operation may run parallel with add/del/gc, i.e. is not one from the next cases - protected by region lock - in a set destroy phase - in a new/temporary set creation phase", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72451", "url": "https://ubuntu.com/security/CVE-2026-72451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix xfrm state cache insertion race The xfrm input state cache insertion code checks the validity of the state before acquiring the global xfrm_state_lock. Thus it's possible for someone else to kill the state after it passed the validity check, and then the insertion will add the dead state to the cache. Fix this by moving the validity check inside the lock. This entire function is called on the input path, where BH must be off (e.g., the caller of this function xfrm_input acquires its spinlocks without disabling BH). So there is no need to disable BH here or take the RCU read lock. Remove both and replace them with an assertion that trips if BH is accidentally enabled on some future calling path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72472", "url": "https://ubuntu.com/security/CVE-2026-72472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: use nfsi->rwsem to protect traversal of the file lock list Lingfeng identified a bug and suggested two solutions, but both appear to have issues. Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case. Furthermore, after commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk. Regarding the bug fixed by commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), it has been resolved after commit 0460253913e5 (\"NFSv4: nfs4_do_open() is incorrectly triggering state recovery\") because all slots are drained before calling nfs4_do_reclaim, which prevents concurrent stateid changes along this path. Also, nfs_delegation_claim_locks does not cause this concurrency either since when _nfs4_proc_setlk is called with NFS_DELEGATED_STATE, no RPC is sent, so nfs4_lock_done is not called. Therefore, nfs4_lock_delegation_recall from nfs_delegation_claim_locks is the first time the stateid is set.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72473", "url": "https://ubuntu.com/security/CVE-2026-72473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decouple req recycling from RPC completion rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer. Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off. The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry. Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied. Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected. Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released. The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74310", "url": "https://ubuntu.com/security/CVE-2026-74310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/net: complete zerocopy ubufs only once vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74345", "url": "https://ubuntu.com/security/CVE-2026-74345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix endpoint/socket association handling Disassociating a socket from an endpoint via siw_socket_disassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within. This fixes a: BUG: KASAN: slab-use-after-free in siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1053 drivers/infiniband/sw/siw/siw_cm.c:1075) which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74361", "url": "https://ubuntu.com/security/CVE-2026-74361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: fix FDP fdpcidx bounds check The fdpcidx bounds check sets n = NUMFDPC + 1 but used > instead of >=, incorrectly accepting fdp_idx when it equals n (i.e. NUMFDPC + 1).", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74401", "url": "https://ubuntu.com/security/CVE-2026-74401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix add msg handle in send_queue ordered In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as \"before(mh->seq, seq)\" will stop to check for older sequence numbers that are ordered in the tail of \"node->send_queue\". The side effects of not having it correct ordered regarding \"before(mh->seq, seq)\" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74406", "url": "https://ubuntu.com/security/CVE-2026-74406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74428", "url": "https://ubuntu.com/security/CVE-2026-74428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix double unlock in rxrpc_recvmsg() Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74433", "url": "https://ubuntu.com/security/CVE-2026-74433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix UAF in rxgk_issue_challenge() Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74434", "url": "https://ubuntu.com/security/CVE-2026-74434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Don't move a peeked OOB message onto the pending queue rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so only unlink it from recvmsg_oobq and then move it onto pending_oobq or free it when the message is actually consumed.", "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-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-74439", "url": "https://ubuntu.com/security/CVE-2026-74439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clear Present bit before tearing down scalable-mode context entry device_pasid_table_teardown() zeroes the 128-bit scalable-mode context entry with context_clear_entry() while the Present bit is still set. This creates a window where the hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behavior or spurious faults. The context-cache invalidation is issued only after the entry has been zeroed, and intel_pasid_free_table() then frees the PASID directory pages, so the IOMMU can keep walking a stale Present=1 entry that points at freed memory. While x86 provides strong write ordering, the compiler may reorder the two 64-bit writes to the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Commit c1e4f1dccbe9d (\"iommu/vt-d: Clear Present bit before tearing down context entry\") fixed this exact pattern in domain_context_clear_one() and the copied-context path, but device_pasid_table_teardown() was not converted. Align it with the \"Guidance to Software for Invalidations\" in the VT-d spec, Section 6.5.3.3, using the same ownership handshake as the sibling fix: clear only the Present bit, flush it to the IOMMU, perform the context-cache invalidation, and only then zero the rest of the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" } ], "log": [ "", " * noble/linux-riscv-7.0: 7.0.0-38.38.1~24.04.1 -proposed tracker (LP: #2165483)", "", " [ Ubuntu-riscv: 7.0.0-38.38.1 ]", "", " * resolute/linux-riscv: 7.0.0-38.38.1 -proposed tracker (LP: #2165484)", " * resolute: llvm-21-dev build-depends breaks cross-builds (LP: #2165407)", " - [Packaging] Fix cross-builds", " * Zfhmin/Zvfhmin not reported when Zfh/Zvfh are present (LP: #2166547)", " - riscv: report Zfhmin/Zvfhmin when Zfh/Zvfh are present", " [ Ubuntu: 7.0.0-38.38 ]", " * resolute/linux: 7.0.0-38.38 -proposed tracker (LP: #2166443)", " * linux: dtbs_install fails on Resolute builders due to uutils install(1)", " EEXIST race under parallel make (LP: #2166356)", " - SAUCE: [Packaging] Serialise dtbs_install to work around uutils", " install(1) race", " * #510/p sleepable raw tracepoint reject from test_verifier in ubuntu_bpf", " failed with resolute (7.0.0-33.33) generic amd64 (LP: #2165872)", " - SAUCE: Revert \"bpf: Verifier support for sleepable tracepoint programs\"", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189)", " - 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", " - seqlock: Allow UBSAN_ALIGNMENT to fail optimizing", " - KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN", " - crypto: tegra - Don't touch bo refcount in host1x bo pin/unpin", " - xprtrdma: Clear receive-side ownership pointers on release", " - Input: ims-pcu - fix logic error in packet reset", " - fuse: fix writeback array overflow when max_pages is one", " - arm64: tegra: Remove fallback compatible for GPCDMA", " - arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234", " - xfrm: propagate -EINPROGRESS from validate_xmit_xfrm()", " - mtd: mtdswap: remove debugfs stats file on teardown", " - mtd: nand: mtk-ecc: stop on ECC idle timeouts", " - btrfs: fallback to transaction csum tree on a commit root csum miss", " - RDMA/cma: Fix hardware address comparison length in netevent callback", " - RDMA/irdma: Remove redundant legacy_mode checks", " - RDMA/erdma: initialize ret for empty receive WR lists", " - RDMA/mana_ib: initialize err for empty send 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: cfg80211: derive S1G beacon TSF from S1G fields", " - wifi: nl80211: validate nested MBSSID IE blobs", " - wifi: nl80211: constrain MBSSID TX link ID range", " - wifi: cfg80211: validate PMSR measurement type data", " - wifi: cfg80211: reject unsupported PMSR FTM location requests", " - wifi: mac80211: avoid non-S1G AID fallback for S1G assoc", " - ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on", " start/stop", " - ASoC: amd: ps: disable MSI on resume in ACP PCI driver", " - ASoC: amd: ps: fix wrong ACP version string in pci_request_regions()", " - ASoC: amd: ps: replace bitwise OR with logical OR in IRQ return check", " - 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", " - cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq", " - udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()", " - ata: sata_dwc_460ex: use platform_get_irq()", " - ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending", " interrupts", " - accel/ivpu: Fix wrong register read in LNL failure diagnostics", " - ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC", " - drm/i915/gt: use correct selftest config symbol", " - powerpc/85xx: Add fsl,ifc to common device ids", " - powerpc/time: Prepare to stop elapsing in dynticks-idle", " - powerpc/vtime: Initialize starttime at boot for native accounting", " - drm/panthor: Check debugfs GEM lock initialization", " - riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()", " - can: j1939: fix lockless local-destination check", " - drm/xe/wopcm: fix WOPCM size for LNL+", " - drm/i915/wm: clear the plane ddb_y entries on plane disable", " - 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: gadget: fsl-udc: fix dev_printk() device", " - 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", " - SAUCE: Revert \"usb: typec: ucsi: Detect and skip duplicate altmodes from", " buggy firmware\"", " - usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware", " - wifi: mwifiex: fix freeze for 60 seconds caused by request_firmware", " - RISC-V: KVM: Serialize virtual interrupt pending state updates", " - Revert \"drm/amd/display: Add missing kdoc for ALLM parameters\"", " - usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits", " - selftests/bpf: Adjust verifier_map_ptr for the map's excl field", " - selftests/bpf: Keep verifier_map_ptr exercising ops pointer access", " - 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", " - btrfs: fix u32 to s64 type conversion in dirty_metadata_bytes accounting", " - ASoC: sun4i-codec: Set quirks.playback_only for H616 codec", " - 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: fix pointer arithmetic in iwl_add_mcc_to_tas_block_list", " - wifi: iwlwifi: validate payload length in iwl_pnvm_complete_fn", " - wifi: iwlwifi: mvm: fix read in wake packet notification handler", " - usb: atm: ueagle-atm: reject descriptors that confuse probe and", " disconnect", " - drivers/virt: pkvm: Fix end calculation in mmio_guard_ioremap_hook()", " - 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", " - selftests/net: ovpn: fix getaddrinfo memory leak in ovpn_parse_remote()", " - ovpn: use monotonic clock for peer keepalive timeouts", " - regulator: mt6358: use regmap helper to read fixed LDO calibration", " - net: phy: marvell: fix return code", " - netlink: specs: rt-link: convert bridge port flag attributes to u8", " - gtp: parse extension headers before reading inner protocol", " - vhost-net: fix TX stall when vhost owns virtio-net header", " - wifi: mac80211: recalculate TIM when a station enters power save", " - pds_core: reject component parameter in legacy firmware update", " - arm64: Correct value returned by ESR_ELx_FSC_ADDRSZ_nL()", " - amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN", " - soreuseport: Clear sk_reuseport_cb before failure in sk_clone().", " - net: Call net_enable_timestamp() before failure in sk_clone().", " - 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", " - selftests: af_unix: add USER_NS config", " - selftests: openvswitch: add config file", " - selftests: ovpn: add IPV6 and VETH configs", " - selftests: ovpn: increase timeout", " - selftests: drv-net: increase timeout", " - ppp: don't store tx skb in the fastpath", " - ppp: annotate concurrent dev->stats accesses", " - ovl: fix trusted xattr escape prefix matching", " - drm/panel: s6e3ha8: fix unmet dependency on DRM_DISPLAY_HELPER", " - 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", " - drm/xe/i2c: Allow per domain unique id", " - iomap: correct the range of a partial dirty clear", " - drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem", " - net: stmmac: xgmac: fix l4 filter port overwrite on register update", " - 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: annotate data races in ppp_generic", " - hinic: remove unused ethtool RSS user configuration buffers", " - raw: annotate lockless match fields in raw_v4_match()", " - 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", " - octeontx2-pf: tc: fix egress ratelimiting", " - net: ipv6: fix dif and sdif mismatch in raw6_icmp_error", " - ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV", " - ice: fix LAG recipe to profile association", " - ipv6: Change allocation flags to match rcu_read_lock section", " requirements", " - ptp: netc: explicitly clear TMR_OFF during initialization", " - mctp: check register_netdevice_notifier() error in mctp_device_init()", " - net: airoha: fix ETS channel derivation in airoha_tc_setup_qdisc_ets()", " - drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay", " - drm: renesas: rzg2l_mipi_dsi: Move rzg2l_mipi_dsi_set_display_timing()", " - drm/tidss: Fix missing drm_bridge_add() call", " - 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/sysfb: Do not page-align visible size of the framebuffer", " - drm/sysfb: Avoid truncating maximum stride", " - drm/amdgpu/gfx9: Fix Ring and IB test fail after mode2", " - drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT", " - drm/sysfb: Return errno code from drm_sysfb_get_visible_size()", " - drm/displayid: fix Tiled Display Topology ID size", " - drm/nouveau/acr: fix missing nvkm_done() in error path of", " nvkm_acr_oneinit()", " - drm/radeon: fix r100_copy_blit for large BOs", " - drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked binds", " - drm/amdkfd: Use kvcalloc to allocate arrays", " - drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips", " - drm/i915/hdcp: require monotonically increasing seq_num_v", " - drm/amd/amdgpu: disable ASPM on VI if pcie dpm is disabled", " - drm/amd/pm: fix smu14 power limit range calculation", " - drm/gfx10: Program DB_RING_CONTROL", " - drm/virtio: Don't detach GEM from a non-created context", " - drm/panthor: return error on truncated firmware", " - drm/amdgpu: Fix VFCT bus number matching with soft filter", " - drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)", " - drm/amd/display: consolidate DCN vblank/flip handling onto", " vupdate_no_lock", " - drm/amd/display: Force PWM backlight on Lenovo Legion 5 15ARH05", " - drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge", " - drm/amd/display: Fix flip-done timeouts on mode1 reset", " - drm/amd/display: Fix missing DCE check in", " dm_gpureset_toggle_interrupts()", " - drm/v3d: Reach the GMP through the hub registers on V3D 7.x", " - 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: imx219: Fix maximum frame length in lines", " - media: iris: Fix use IRQF_NO_AUTOEN when requesting the IRQ", " - media: marvell-cam: fix missing pci_disable_device() on remove", " - media: nuvoton: npcm-video: fix error handling in npcm_video_init()", " - 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: qcom: camss: Fix RDI streaming for CSID 680", " - media: qcom: camss: Fix RDI streaming for CSID GEN2", " - media: qcom: camss: Fix RDI streaming for CSID GEN3", " - media: rzg2l-cru: Skip ICnMC configuration when ICnSVC is used", " - media: synopsys: hdmirx: Fix HPD lane hold time", " - 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: v4l2-subdev: Fail {enable,disable}_streams and s_streaming nicely", " - media: vb2: use ssize_t for vb2_read/vb2_write", " - media: verisilicon: Export only needed pixels formats", " - media: vidtv: fix reference leak on failed device registration", " - media: vimc: fix reference leak on failed device registration", " - media: vpif_capture: fix OF node reference imbalance", " - ALSA: hda/realtek: Fix speakers on Lunnen Ground 14", " - ALSA: hda: codecs: hdmi: disable keep-alive before audio format change", " - wifi: brcmfmac: set F2 blocksize to 256 for BCM43752", " - wifi: ath11k: fix refcount leak in ath11k_ahb_fw_resources_init()", " - staging: rtl8723bs: fix inverted HT40 secondary channel offset", " - platform/loongarch: laptop: Explicitly reset bl_powered state when", " suspend", " - rust_binder: only print failure if error has source", " - rust: time: fix as_micros_ceil() to round correctly for negative Delta", " - rust: allow `clippy::unwrap_or_default` globally", " - objtool/rust: add one more `noreturn` Rust function for Rust 1.99.0", " - LoongArch: Fix address space mismatch in kexec command line lookup", " - LoongArch: Fix oops during single-step debugging", " - LoongArch: Move jump_label_init() before parse_early_param()", " - LoongArch: Retrieve CPU package ID from PPTT when available", " - x86/boot/compressed: Disable jump tables", " - uio_hv_generic: Bind to FCopy device by default", " - serial: sc16is7xx: implement gpio get_direction() callback", " - selftests: ntsync: correct CONFIG_NTSYNC name", " - tracing: Fix context switch counter truncation", " - 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()", " - mptcp: decrement subflows counter on failed passive join", " - mptcp: only set DATA_FIN when a mapping is present", " - mm/kmemleak: fix checksum computation for per-cpu objects", " - mm/huge_memory: set PG_has_hwpoisoned only after new folio head is", " established", " - ceph: fix refcount leak in ceph_readdir()", " - ceph: fix writeback_count leak in write_folio_nounlock()", " - ASoC: fsl: imx-card: Skip sysclk reset for active DAIs in shutdown", " - ASoC: fsl_sai: Fix spurious BCLK on resume by clearing BYP", " - io_uring/rw: fix missing ERESTARTSYS conversion in read paths", " - iommu/vt-d: Disallow SVA if page walk is not coherent", " - net: stmmac: intel: skip SerDes reconfig when rate is unchanged", " - net: pcs: xpcs: fix SGMII state reading", " - proc: Fix broken error paths for namespace links", " - s390/ptff: Export ptff_function_mask[]", " - smb: client: handle STATUS_STOPPED_ON_SYMLINK responses without a", " symlink target", " - ice: use READ_ONCE() to access cached PHC time", " - ovpn: hold peer before scheduling keepalive work", " - vsock/virtio: collapse receive queue under memory pressure", " - watchdog: s32g_wdt: remove incorrect options in watchdog_info struct", " - drm/amd/pm: fix amdgpu_pm_info power display units", " - drm/amd/pm: make pp_features read-only when scpm is enabled", " - drm/amdgpu/jpeg: fix jpeg_v4_0_3_is_idle detection", " - drm/amdgpu/jpeg: fix jpeg_v5_0_1_is_idle detection", " - drm/amdgpu/soc24: reset dGPU if suspend got aborted", " - drm/amdgpu: fix resource leak on ACP reset timeout", " - drm/amd/pm: fix smu13 power limit range calculation", " - drm/amdgpu: fix check in amdgpu_hmm_invalidate_gfx", " - drm/xe/uapi: Reject coh_none PAT index for CPU_ADDR_MIRROR", " - net: qrtr: ns: Raise node count limit to 512", " - drm/amd/display: Fix DTB DTO updates breaking live pixel rate sources", " - audit: widen ino fields to u64", " - audit: use 'unsigned int' instead of 'unsigned'", " - xfs: don't replace the wrong part of the cow fork", " - netfilter: nf_tables: remove register tracking infrastructure", " - drm: drop lib from header search path.", " - SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlists", " - SUNRPC: Return an error from xdr_buf_to_bvec() on overflow", " - SAUCE: Revert \"mm/sparse-vmemmap: fix vmemmap accounting underflow\"", " - mm/sparse-vmemmap: fix vmemmap accounting underflow", " - mmc: vub300: rename probe error labels", " - net: mana: Optimize irq affinity for low vcpu configs", " - bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c", " - bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()", " - pmdomain: imx93-blk-ctrl: convert to devm_* only", " - rust: allow `suspicious_runtime_symbol_definitions` lint for Rust >=", " 1.98", " - rust: device: avoid trailing ; in printing macros", " - sched_ext: Skip ops.set_weight() for disabled tasks", " - sched_ext: Annotate ksyncs with __rcu in alloc/free_kick_syncs()", " - reset: spacemit: k3: fix USB2 ahb reset", " - wifi: cfg80211: reject empty PMSR peer lists", " - ASoC: amd: acp: Fix linker error with SDCA quirks", " - [Config] Adjust config SND_SOC_ACPI_AMD_SDCA_QUIRKS", " - sched_ext: Enable tick for finite slices on nohz_full", " - Bluetooth: mgmt: Translate HCI reason in Device Disconnected event", " - riscv: Gate FUNCTION_ALIGNMENT_4B on DYNAMIC_FTRACE", " - spi: cadence-quadspi: Fix indirect write timeout when DMA read mode is", " enabled", " - drm/xe: Assign queue name in time for drm_sched_init", " - drm/xe: add WQ_PERCPU to alloc_workqueue users", " - selftests: netconsole: only restore MAC when it changed on resume", " - wifi: ath10k: fix skb leak on incomplete msdu during rx pop", " - wifi: ath12k: Fix low MLO RX throughput on WCN7850", " - iommu/amd: Fix nested domain leak", " - arm_mpam: Fix software reset values of MPAMCFG_PRI", " - arm_mpam: Fix MPAMCFG_MBW_PBM register setting", " - hwmon: Drop unused i2c driver_data", " - hwmon: Use named initializers for arrays of i2c_device_data", " - hwmon: (pmbus/max34440): add support adpm12250", " - hwmon: (pmbus/max34440) block unsupported VIN and IIN limit registers", " - drm/i915/backlight: Remove DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check for", " DPCD backlight", " - selftests/net: Fix tun IPv6 test addresses to avoid 6to4 range", " - geneve: fix hint header definition wrt endianness", " - geneve: ensure the skb is writable before fixing its headers", " - accel: ethosu: Handle U85 internal chaining buffer", " - selftests: drv-net: convert so_txtime to drv-net", " - cifs: prevent readdir from changing file size due to stale directory", " metadata", " - wifi: mt76: fix airoha_npu dependency tracking", " - [Config] Fix config dependencies for MT76_NPU", " - drm/panel: ilitek-ili9882t: fix unmet dependency for", " DRM_PANEL_ILITEK_ILI9882T", " - iomap: fix incorrect did_zero setting in iomap_zero_iter()", " - mpls: Set rt->rt_nhn just before returning from mpls_nh_build_multi().", " - LoongArch: BPF: Zero-extend signed ALU32 div/mod results", " - bnge/bng_re: fix ring ID widths", " - pidfs: make pidfs_ino_lock static", " - LoongArch: BPF: Fix memory leak in bpf_jit_free()", " - drm/exynos: fbdev: Remove offset into screen_buffer", " - drm/tegra: fbdev: Remove offset into framebuffer memory", " - drm/i915/cdclk: Fix up CDCLK_FREQ_DECIMAL without a full PLL re-enable", " - drm/amd/pm: re-enable MC access after PrepareMp1ForUnload on SMU V15", " APUs", " - bitmap: add test_zero_nbits()", " - drm/xe: Add compact-PT and addr mask handling for page reclaim", " - drm/amd/display: Restore periodic detection for DCN35", " - drm/amdgpu: Respect placement requirements in amdgpu_gtt_mgr functions", " - drm/amdkfd: Use exclusive bounds for SVM split alignment checks", " - drm/i915/mtl+: Enable PPS before PLL", " - drm/xe/oa: Fix offset alignment for MERT WHITELIST_OA_MERT_MMIO_TRG", " - drm/xe/nvm: fix writable override for CRI", " - drm/amdgpu: Check for multiplication overflow in checkpoint stack size", " - drm/amdkfd: Guard m->cp_hqd_eop_control setting by", " q->eop_ring_buffer_size", " - drm/amdkfd: free MQD managers on DQM init failures", " - drm/amd/display: set MSA MISC1 bit 6 when using VSC SDP for DCE 11.x", " - drm/amdgpu: add the doorbell index input for suspending userq", " - drm/amdgpu: remove deadlocks from amdgpu_userq_pre_reset", " - drm/amd: Create a device link between APU display and XHCI devices", " - drm/pagemap: Clear driver-provided PFNs from migration PFN array", " - mm: add gpu active/reclaim per-node stat counters (v2)", " - drm/ttm: use gpu mm stats to track gpu memory allocations. (v4)", " - drm/ttm: Fix GPU MM stats during pool shrinking", " - drm/ttm/pool: back up at native page order", " - drm/gpusvm: Zero HMM PFNs before scanning ranges", " - media: mali-c55: Add missing of_reserved_mem_device_release()", " - media: mali-c55: Disable pm_runtime on probe error", " - media: mali-c55: Power-off the peripheral in remove()", " - media: qcom: camss: Fix RDI streaming for CSID 340", " - media: rzv2h-ivc: Wait for frame end in stop_streaming", " - media: ti: vpe: Fix fwnode_handle leak in vip_probe_complete()", " - media: ti: vpe: Fix the error code of devm_request_irq()", " - media: uapi: rkisp: Correct name version enum", " - wifi: mt76: restrict NPU/PPE active checks to MMIO devices", " - LoongArch: Fix build errors due to wrong instructions for 32BIT", " - LoongArch: Increase TASK_STRUCT_OFFSET up to 2040 for 32BIT", " - firmware: stratix10-svc: fix teardown order in remove to prevent race", " - firmware: stratix10-svc: handle NO_RESPONSE in async poll", " - tracing: perf: Fix stale head for perf syscall tracing", " - 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\"", " - selftests: mptcp: userspace_pm: fix undefined variable port", " - m68k: avoid -Wunused-but-set-parameter in clear_user_page()", " - mm/memory-failure: trace: change memory_failure_event to ras subsystem", " - mm/slub: fix lost local objects when bulk remote free batch fills", " - mm/slab: fix a memory leak due to bootstrapping sheaves twice", " - drm/amdgpu: rework userq fence driver alloc/destroy", " - drm/amdgpu: rework userq fence signal processing", " - drm/amdgpu/gfx11: fix EOP interrupt routing for KQ and userq", " - drm/amdgpu/gfx12: fix EOP interrupt routing for KQ and userq", " - drm/amdgpu/mes11: set doorbell offset for suspending userq", " - selftests: drv-net: add missing kconfig for psp.py", " - mm/sparse-vmemmap: pass @pgmap argument to memory deactivation paths", " - mm/sparse-vmemmap: fix DAX vmemmap accounting with optimization", " - selftests: drv-net: cope with slow env in so_txtime.py test", " - selftests: drv-net: so_txtime: relax variance bounds", " - cifs: fix time_last_write stamp placement in setattr/truncate paths", " - cifs: consolidate time_last_write stamp into _cifsFileInfo_put()", " - Upstream stable to v6.18.41, v6.18.42, v6.18.43, v7.1.6, v7.1.7", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68480", " - x86/bugs: Make Safe-RET robust against interrupt injection", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68105", " - drm/amdgpu: Fix kernel panic during driver load failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68109", " - drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68114", " - drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68431", " - ksmbd: validate minimum PDU size for transform requests", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68138", " - net/sched: serialize qdisc_rtab_list against concurrent get/put", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68082", " - libceph: fix two unsafe bare decodes in decode_lockers()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68159", " - libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68163", " - mm/page_vma_mapped: fix device-private PMD handling", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68166", " - userfaultfd: prevent registration of special VMAs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68170", " - mptcp: fix stale skb->sk reference on subflow close", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68177", " - tracing: Delay module ref count for \"enable_event\" trigger", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68191", " - wifi: ath12k: fix NULL pointer dereference in rhash table destroy", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64586", " - wifi: brcmfmac: drain bus_reset work on device removal", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68208", " - media: ti: vpe: Fix the error code of devm_kzalloc() in", " vip_probe_slice()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68224", " - media: mali-c55: Fix possible ERR_PTR in enable_streams", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68237", " - drm/amdgpu/userq: fix indefinite fence wait during GPU reset", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68240", " - drm/gpusvm: publish dpagemap early to avoid device mapping leak on error", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68242", " - drm/i915/gt: Fix NULL deref on sched_engine alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68254", " - drm/i915/vrr: require valid min/max vfreq for VRR", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68436", " - drm/amd/display: use kvzalloc to allocate struct dc", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68447", " - drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68264", " - drm/xe/pt: Reset current_op in xe_pt_update_ops_init()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68265", " - drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68267", " - drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68273", " - drm/amdgpu: Fix context pstate override handling", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68274", " - drm/xe/guc: Fix buffer overflow in steered register list allocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68283", " - tracing: Fix use-after-free freeing trigger private data", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68286", " - drop_monitor: perform u64_stats updates under IRQ-disabled section", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68287", " - drop_monitor: fix size calculations for 64-bit attributes", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68288", " - net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68289", " - tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68291", " - idpf: fix max_vport related crash on allocation error during init", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68303", " - drm/vc4: hvs/v3d: Fix null dereference in unbind", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68312", " - cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain", " paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68316", " - accel: ethosu: Fix element size accounting for cmd stream validation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68322", " - rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68440", " - net: txgbe: fix heap overflow when reading module EEPROM", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68323", " - tipc: serialize udp bearer replicast list updates", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68441", " - net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68337", " - bpf: Reject redirect helpers without a bpf_net_context", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68345", " - arm_mpam: guard MBWU state before adding it to garbage", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68347", " - iommu/amd: Fix IRQ unsafe locking in gdom allocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68375", " - bnxt_en: Handle partially initialized auxiliary devices", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68382", " - drm/xe/guc: Hold device ref until queue teardown completes", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68383", " - drm/xe/guc: Keep scheduler timeline name alive", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68390", " - Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68399", " - bpf: Fix UAF in sock clone early bailouts", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68404", " - wifi: cfg80211: use wiphy work for socket owner autodisconnect", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64581", " - xfrm: fix sk_dst_cache double-free in xfrm_user_policy()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68093", " - KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision", " after hotplug", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68367", " - usb: gadget: f_tcm: synchronize delayed set_alt with teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68164", " - mm/damon/core: disallow overlapping input ranges for damon_set_regions()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68165", " - mm/damon/core: validate ranges in damon_set_regions()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68095", " - fuse-uring: fix race between registration and connection abortion", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68096", " - audit: fix recursive locking deadlock in audit_dupe_exe()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68147", " - fscrypt: Avoid dynamic allocation in fscrypt_get_devices()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68097", " - ksmbd: validate ACE size against SID sub-authorities", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68098", " - ksmbd: bound DACL dedup walk to copied ACEs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68099", " - ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68100", " - ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68173", " - ublk: wait on ublk_dev_ready() instead of ub->completion", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68104", " - drm/amdgpu: invoke pm_genpd_remove() before freeing genpd", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68106", " - drm/amdgpu: fix division by zero with invalid uvd dimensions", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68429", " - drm/dp_mst: Handle torn-down topology gracefully in", " drm_dp_mst_topology_queue_probe()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68107", " - drm/amdgpu/vcn4: avoid rereading IB param length", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68108", " - drm/amdgpu/vce: fix integer overflow in image size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68110", " - drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68111", " - drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68112", " - drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68430", " - drm/amdgpu/gfx8: drop unecessary BUG_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68113", " - drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68246", " - drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68115", " - drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68116", " - vxlan: mdb: Fix source list corruption on a failed replace", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68117", " - tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68118", " - tcp: challenge ACK for non-exact RST in SYN-RECEIVED", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68119", " - tcp: initialize standalone TCP-AO response padding", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68120", " - rtase: Workaround for TX hang caused by hardware packet parsing", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68121", " - pppoe: reload header pointer after dev_hard_header()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68122", " - ovpn: fix peer refcount leak in TCP error paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68123", " - openvswitch: fix GSO userspace truncation underflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68124", " - mctp: serial: handle zero-length frames to prevent rx buffer overflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68125", " - mac802154: llsec: reject frames shorter than the authentication tag", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68126", " - mac802154: hold an interface reference across the scan worker", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68127", " - ila: reload IPv6 header after pskb_may_pull in checksum adjust", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68128", " - ice: reject out-of-range ptype in ice_parser_profile_init", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68129", " - gve: fix Rx queue stall on alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68130", " - ksmbd: defer destroy_previous_session() until after NTLM authentication", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68131", " - rbd: Reset positive result codes to zero in object map update path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68132", " - super: fix emergency thaw deadlock on frozen block devices", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68133", " - ice: fix PTP Call Trace during PTP release", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68134", " - ptp: ptp_s390: Add missing facility check", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68135", " - net: hip04: fix RX buffer leak on build_skb failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68136", " - net: gro: fix double aggregation of flush-marked skbs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68137", " - net/x25: fix use-after-free in x25_kill_by_neigh()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68139", " - net/mlx5e: Use sender devcom for MPV master-up", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68140", " - net/iucv: fix use-after-free of a severed iucv_path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68141", " - net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68142", " - geneve: require CAP_NET_ADMIN in the device netns for changelink", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68143", " - net: slip: serialize receive against buffer reallocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68432", " - vxlan: require CAP_NET_ADMIN in the device netns for changelink", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68144", " - phonet: pep: fix use-after-free in pep_get_sb()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68145", " - iomap: fix out-of-bounds bitmap_set() with zero-length range", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68146", " - ftrace: Add global mutex to serialize trace_parser access", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68148", " - fscrypt: Add missing superblock check in find_or_insert_direct_key()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68149", " - fs: preserve ACL_DONT_CACHE state in forget_cached_acl()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68150", " - fs/super: fix emergency thaw double-unlock of s_umount", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68151", " - binfmt_elf_fdpic: only honour the first PT_INTERP", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68152", " - amt: fix use-after-free in AMT delayed works", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68153", " - libceph: remove debugfs files before client teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68154", " - libceph: reject zero bucket types in crush_decode", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68155", " - libceph: Reject monmaps advertising zero monitors", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68156", " - libceph: refresh auth->authorizer_buf{,_len} after authorizer update", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68157", " - libceph: guard missing CRUSH type name lookup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68158", " - libceph: Fix multiplication overflow in decode_new_up_state_weight()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68433", " - libceph: bound get_version reply decode to front len", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68160", " - ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68161", " - sctp: close UDP tunnel sockets during netns teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68162", " - sctp: avoid auth_enable sysctl UAF during netns teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64564", " - sctp: don't free the ASCONF's own transport in DEL-IP processing", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68168", " - afs: Fix afs_edit_dir_remove() to get, not find, block 0", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68169", " - mptcp: pm: userspace: fix use-after-free in get_local_id", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68172", " - arm64: make huge_ptep_get handled unaligned addresses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68174", " - tracing: Fix union collision of module and refcnt for dynamic events", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68175", " - tracing: Fix resource leak on mmiotrace trace_pipe close", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68176", " - tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68178", " - misc: nsm: pin the module while the device is open", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68179", " - misc: nsm: only unlock nsm_dev on post-lock error paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68180", " - intel_th: fix MSC output device reference leak", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68181", " - mei: bus: access mei_device under device_lock on cleanup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68434", " - serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR", " platforms", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68182", " - comedi: comedi_parport: deal with premature interrupt", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68183", " - firmware: stratix10-svc: fix memory leaks and list corruption bugs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64563", " - rhashtable: clear stale iter->p on table restart", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68184", " - cdrom: fix stack out-of-bounds read in CDROMVOLCTRL", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68186", " - binfmt_misc: set have_execfd only once the interpreter is opened", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68187", " - exec: fix unsigned loop counter wrap in transfer_args_to_stack()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68188", " - Bluetooth: RFCOMM: Fix session UAF in set_termios", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68189", " - Bluetooth: hci_sync: Protect UUID list traversal", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68190", " - staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68192", " - wifi: brcmfmac: make release_scratchbuffers idempotent", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68193", " - wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68194", " - wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68195", " - wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68196", " - wifi: wilc1000: validate assoc response length before subtracting header", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68197", " - wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-", " oper", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68198", " - wifi: ath6kl: fix use-after-free in aggr_reset_state()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68199", " - wifi: ath6kl: fix OOB access from firmware ADDBA window size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68200", " - ALSA: timer: don't re-enter an instance callback that is still running", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68201", " - ALSA: timer: drain a slave's callback before its master detaches it", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68202", " - ALSA: seq: close a re-opened queue timer in the destructor", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68203", " - media: vivid: fix cleanup bugs in vivid_init()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68204", " - media: vivid: check for vb2_is_busy() when toggling caps", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68205", " - media: v4l2-fwnode: Fix subdev owner overwritten in", " v4l2_async_register_subdev_sensor()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68206", " - media: v4l2-ctrls: validate HEVC active reference counts", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68207", " - media: ti: vpe: unwind v4l2 device registration on probe error", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68209", " - media: sun4i-csi: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68210", " - media: stm32: dcmi: unregister notifier on probe failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68211", " - media: stm32-dcmipp: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68212", " - media: saa7134: Fix a possible memory leak in saa7134_video_init1", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68213", " - media: rtl2832_sdr: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68214", " - media: rtl2832: fix use-after-free in rtl2832_remove()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68215", " - media: radio-si476x: Unregister v4l2_device on probe failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68216", " - media: pwc: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68217", " - media: pwc: Drain fill_buf on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68218", " - media: pci: dm1105: Free allocated workqueue", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68219", " - media: nxp: imx8-isi: Fix potential out-of-bounds issues", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68220", " - media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and", " pipe", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68221", " - media: nuvoton: npcm-video: fix memory leaks in probe and remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68222", " - media: msi2500: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68223", " - media: meson: vdec: Fix memory leak in error path of vdec_open", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68225", " - media: i2c: alvium: fix critical pointer access in alvium_ctrl_init", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68226", " - media: cx23885: add ioremap return check and cleanup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68227", " - media: cx231xx: fix devres lifetime", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68228", " - media: chips-media: wave5: Move src_buf Removal to finish_encode", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68229", " - media: cedrus: skip invalid H.264 reference list entries", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68230", " - media: amlogic-c3: Add validations for ae and awb config", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68231", " - media: airspy: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68232", " - drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68445", " - drm/vc4: Prevent shader BO mappings from becoming writable", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68446", " - drm/vmwgfx: Validate vmw_surface_metadata::array_size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68233", " - drm/vc4: Shut down BO cache timer before teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68234", " - drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68235", " - drm/amd/display: dce100: skip non-DP stream encoders for DP MST", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68236", " - drm/amd/display: set new_stream to NULL after release", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68238", " - drm/amdgpu: Release VFCT ACPI table reference", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68239", " - drm/ttm: Account for NULL and handle pages in ttm_pool_backup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68241", " - drm/i915/mst: limit DP MST ESI service loop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68243", " - drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68244", " - drm/i915/gem: Do not leak siblings[] on proto context error", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68245", " - drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68247", " - drm/i915/bios: range check LFP Data Block panel_type2", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68248", " - drm/i915: Return NULL on error in active_instance", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68249", " - drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68250", " - drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68251", " - drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68252", " - drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68253", " - drm/i915/hdcp: check streams[] bounds before overflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68255", " - drm/virtio: bound EDID block reads to the response buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68256", " - drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path", " leaks prev_sink reference", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68257", " - drm/amdkfd: fix 32-bit overflow in CWSR total size calculation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68258", " - drm/amdkfd: Check bounds on CRIU restore queue type and mqd size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68259", " - drm/amdkfd: Check bounds in allocate_event_notification_slot", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68260", " - drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68261", " - drm/imagination: fix error checking of pvr_vm_context_lookup()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68262", " - drm/imagination: Fix user array stride in pvr_set_uobj_array()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68263", " - drm/imagination: Fix double call to drm_sched_entity_fini()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68266", " - drm/xe: Hold a dma-buf reference for imported BOs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68268", " - drm/xe: Return error on non-migratable faults requiring devmem", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68269", " - drm/i915/gem: Add missing nospec on parallel submit slot", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68270", " - drm/sysfb: Avoid possible truncation with calculating visible size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68271", " - drm/nouveau: fix reversed error cleanup order in ucopy functions", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68272", " - drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68275", " - drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68276", " - drm/amdgpu/gfx: fix cleaner shader IB buffer overflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68277", " - drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68437", " - drm/imagination: Fit paired fragment job in the correct CCCB", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68278", " - drm/dp/mst: fix buffer overflows in sideband chunk accumulation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68279", " - drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68280", " - drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68281", " - drm/imagination: Count paired job fence as dependency in prepare_job()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68282", " - drm/rockchip: analogix_dp: Add missing error check for", " platform_get_resource()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68284", " - bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68290", " - rds: tcp: unregister sysctl before tearing down listen socket", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68292", " - ice: prevent tstamp ring allocation for non-PF VSI types", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68293", " - net/mlx5: Fix MCIA register buffer overflow on 32 dword reads", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68294", " - net: qrtr: restrict socket creation to the initial network namespace", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68296", " - net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64575", " - bpf: tcp: fix double sock release on batch realloc", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68297", " - tipc: fix u16 MTU truncation in media and bearer MTU validation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68298", " - drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68299", " - vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68300", " - sctp: auth: verify auth requirement when auth_chunk is NULL", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68301", " - net: hsr: fix memory leak on slave unregistration by removing synced", " VLANs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68302", " - amt: re-read skb header pointers after every pull", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68448", " - ovl: check access to copy_file_range source with src mounter creds", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68304", " - wifi: brcmfmac: fix 802.1X-SHA256 call trace warning", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68306", " - wifi: mt76: mt7996: fix possible NULL-pointer deref in", " mt7996_mcu_sta_bfer_eht()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68307", " - wifi: mt76: mt7925: fix crash in reset link replay", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68308", " - wifi: mt76: mt7996: check pointer returned by", " mt76_connac_get_he_phy_cap()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68439", " - wifi: mt76: mt7925: fix possible NULL-pointer deref in", " mt7925_mcu_bss_he_tlv()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68309", " - wifi: mt76: connac: fix possible NULL-pointer deref in", " mt76_connac_mcu_uni_bss_he_tlv()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68310", " - wifi: mt76: mt7915: guard HE capability lookups", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68311", " - wifi: mt76: mt7925: guard link STA in decap offload", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68313", " - tipc: fix infinite loop in __tipc_nl_compat_dumpit", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64576", " - nexthop: initialize extack in nh_res_bucket_migrate()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64577", " - gtp: check skb_pull_data() return in gtp1u_send_echo_resp()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68314", " - net: mctp i3c: clean up notifier and buses if driver register fails", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68315", " - sctp: validate stream count in sctp_process_strreset_inreq()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68317", " - pds_core: fix auxiliary device add/del races", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68318", " - pds_core: fix use-after-free on workqueue during remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68319", " - pds_core: fix deadlock between reset thread and remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68320", " - sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68321", " - net: txgbe: fix FDIR filter leak on remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68324", " - iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68325", " - iommu/amd: Bound the early ACPI HID map", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68326", " - wifi: mwifiex: bound uAP association event IEs to the event buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68327", " - wan: wanxl: Only reset hardware after BAR mapping", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68328", " - nfp: Check resource mutex allocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64574", " - wifi: mac80211: tear down new links on vif update error path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68329", " - iommu/amd: Wait for completion instead of returning early in", " iommu_completion_wait()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68330", " - net: airoha: Fix DMA direction for NPU mailbox buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68331", " - dpaa2-eth: put MAC endpoint device on disconnect", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68332", " - net: airoha: Fix potential use-after-free in airoha_ppe_deinit()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68333", " - dpaa2-switch: put MAC endpoint device on disconnect", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68334", " - rxrpc: fix io_thread race in rxrpc_wake_up_io_thread()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68335", " - rds: drop incoming messages that cross network namespace boundaries", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68336", " - bonding: fix devconf_all NULL dereference when IPv6 is disabled", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68338", " - net/packet: avoid fanout hook re-registration after unregister", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68339", " - Bluetooth: btusb: validate Realtek vendor event length", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68340", " - hwmon: occ: validate poll response sensor blocks", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68341", " - ovpn: fix use after free in unlock_ovpn()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68342", " - ovpn: avoid putting unrelated P2P peer on socket release", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68343", " - smb: client: validate DFS referral PathConsumed", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68346", " - ALSA: hda: cs35l41: validate and free ACPI mute object", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68348", " - ASoC: tas2781: bound firmware description string parsing", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68450", " - btrfs: free mapping node on duplicate reloc root insert", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68442", " - btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68349", " - wifi: carl9170: fix buffer overflow in rx_stream failover path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68350", " - wifi: carl9170: fix OOB read from off-by-two in TX status handler", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68351", " - wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68352", " - wifi: ath6kl: fix OOB read from firmware IE lengths in connect event", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68353", " - wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68354", " - firewire: net: Fix fragmented datagram reassembly", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68355", " - wifi: ath11k: fix potential buffer underflow in", " ath11k_hal_rx_msdu_list_get()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68356", " - watchdog: airoha: Prevent division by zero when clock frequency is zero", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68357", " - watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68358", " - hwmon: (nzxt-kraken3) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68359", " - hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68443", " - hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68360", " - hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68361", " - hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68362", " - wifi: ath11k: fix NULL pointer dereference in", " ath11k_hal_srng_access_begin", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68363", " - wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware", " request", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68365", " - USB: serial: io_edgeport: cap received transmit credits", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68366", " - usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64583", " - usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before", " teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68368", " - usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68369", " - usb: gadget: printer: fix infinite loop in printer_read()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64584", " - usb: gadget: f_midi: cancel pending IN work before freeing the midi", " object", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68370", " - usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68371", " - usb: musb: omap2430: Do not put borrowed of_node in probe", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68373", " - wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68374", " - usb: core: sysfs: add lock to bos_descriptors_read()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64569", " - mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68376", " - sctp: fix auth_hmacs array size in struct sctp_cookie", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68377", " - net/sched: act_tunnel_key: Defer dst_release to RCU callback", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68378", " - dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68379", " - tcp: fix TIME_WAIT socket reference leak on PSP policy failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68380", " - accel/amdxdna: Fix use-after-free of mm_struct in job scheduler", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64578", " - ksmbd: validate compound request size before reading StructureSize2", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68381", " - ksmbd: pin conn during async oplock break notification", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68384", " - drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68385", " - s390/checksum: Fix csum_partial() without vector facility", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68386", " - bpf, sockmap: Reject unhashed UDP sockets on sockmap update", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68387", " - can: raw: add locking for raw flags bitfield", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68388", " - smb/client: handle overlapping allocated ranges in fallocate", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68389", " - Bluetooth: hci_qca: Clear memdump state on invalid dump size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68391", " - Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68392", " - Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68393", " - Bluetooth: hci_sync: extend conn_hash lookup critical sections", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68394", " - Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64573", " - Bluetooth: qca: fix NVM tag length underflow in TLV parser", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68449", " - ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-", " scanning", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68395", " - ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is", " registered", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68396", " - scsi: core: wake eh reliably when using scsi_schedule_eh", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68397", " - net/iucv: take a reference on the socket found in afiucv_hs_rcv()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64572", " - ipv4: fib: free fib_alias with kfree_rcu() on insert error path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68398", " - ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68400", " - firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset", " calculation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68401", " - firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68402", " - wifi: cfg80211: bound element ID read when checking non-inheritance", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68403", " - wifi: brcmfmac: initialize SDIO data work before cleanup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68405", " - wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68406", " - wifi: cfg80211: validate PMSR FTM preamble range", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68407", " - wifi: nl80211: free RNR data on MBSSID mismatch", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68408", " - wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64571", " - wifi: p54: validate RX frame length in p54_rx_eeprom_readback()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68409", " - wifi: mac80211: defer link RX stats percpu free to RCU", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68410", " - wifi: libertas: fix memory leak in helper_firmware_cb()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64570", " - wifi: mac80211: fix fils_discovery double free on alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64568", " - wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68411", " - wifi: mac80211_hwsim: clamp virtio RX length before skb_put", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68412", " - wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68413", " - wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68414", " - wifi: cfg80211: cancel sched scan results work on unregister", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64579", " - xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64580", " - xfrm6: clear dst.dev on error to avoid double netdev_put in", " xfrm6_fill_dst()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64566", " - xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68415", " - xfrm: clear mode callbacks after failed mode setup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68416", " - mtd: fix double free and WARN_ON in add_mtd_device() error paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68417", " - RDMA/siw: publish QP after initialization", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68418", " - RDMA/irdma: Prevent user-triggered null deref on QP create", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68419", " - RDMA/irdma: Prevent rereg_mr for non-mem regions", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68420", " - xfrm: reject optional IPTFS templates in outbound policies", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68421", " - sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68444", " - firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68422", " - btrfs: fix root leak if its reloc root is unexpected in", " merge_reloc_roots()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64567", " - btrfs: reject free space cache with more entries than pages", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68425", " - IB/mad: Drop unmatched RMPP responses before reassembly", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68426", " - xfrm: fix stale skb->prev after async crypto steals a GSO segment", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64565", " - Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68427", " - gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68428", " - KVM: x86/mmu: Fix use-after-free on vendor module reload", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64562", " - KVM: nVMX: Hide shadow VMCS right after VMCLEAR", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64561", " - KVM: x86: Check for invalid/obsolete root *after* making MMU pages", " available", " * resolute: llvm-21-dev build-depends breaks cross-builds (LP: #2165407)", " - [Packaging] Fix cross-builds", " * Resolute Stable Update v6.18.40, v7.1.5 bugs (LP: #2165040)", " - accel/amdxdna: Allow forcing IOVA-based DMA via module parameter", " - SAUCE: bpf: Add missing NULL argument to zap_page_range_single", " - accel/amdxdna: Return ERR_PTR on dma_alloc_noncoherent failure", " - accel/amdxdna: Fix memory leak in amdxdna_iommu_alloc()", " * [SRU][HPE] Take Intel platform into account for old microcode checks", " (LP: #2161748)", " - x86/microcode: Refactor platform ID enumeration into a helper", " - x86/cpu: Add platform ID to CPU info structure", " - x86/cpu: Add platform ID to CPU matching structure", " - x86/microcode: Add platform mask to Intel microcode \"old\" list", " - x86/microcode: Do not access MSR_IA32_PLATFORM_ID when running as a", " guest", " * ice: E810 interface fails to initialize (ice_init_hw failed: -5) during", " NVM read (LP: #2163508)", " - ice: acquire NVM lock around each flash read", " * WWAN modem unresponsive after freeze on Dell systems with DW5826e", " (LP: #2163214)", " - platform/x86: dell-dw5826e: Add reset driver for DW5826e", " - platform/x86: dell-dw5826e: fix ACPI _DSM function index and bitmask", " usage", " - [Config] Add CONFIG_DELL_DW5826E_RESET=m", " * amdgpu panel self-refresh on dual-gpu laptops causes complete built-in", " panel freeze and severe system instability (LP: #2162904)", " - SAUCE: drm/amdgpu: Do not enter PSR if multiple displays are active", " * linux 7.0: dw9719 VCM never binds, disabling all IPU3 cameras (regression,", " fixed upstream) (LP: #2162045)", " - media: dw9719: Add back the I²C device id table", " * Fix TAS2783 SoundWire amp resume timeout >5s (LP: #2164967)", " - soundwire: Add a helper function to wait for device initialisation", " - ASoC: tas2783: Use new SoundWire enumeration helper", " - soundwire: Move wait for initialisation helper to header", " - ASoC: codecs: tas2783-sdw: Propagate regcache_sync() errors", " - ASoC: tas2783-sdw: drop stale regcache on uninitialized re-attach", " * Linux, Ubuntu, 24.04, System hangs for about 10 seconds when unplug", " external monitor cable on non TBT dock (LP: #2160082)", " - SAUCE: drm/i915/tc: Revert forced DP-alt connected workaround", " * Speakers not detected on HP systems with TI TAS2783 SoundWire amps", " (LP: #2164504)", " - ASoC: sdw_utils: Add missed component_name strings for TI amps", " * [TWL][Desktop] intel_dmc_wait_fw_load() merge to Ubuntu next release", " (LP: #2156316)", " - SAUCE: drm/i915/dmc: fix assert_dmc_loaded WARN during async firmware", " load", " * 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", " * Ethernet adapter unusable after suspend/resume on Advantech systems with", " Intel I226-V (LP: #2163375)", " - igc: fix netdev not re-attached after resume if interface is down", " * ice: fix stale -EBUSY on resume of Intel E810 (LP: #2162803)", " - ice: wait for reset completion in ice_resume()", " * idxd: crash-kernel NULL-pointer Oops in `destroy_workqueue()` breaks kdump", " on Intel DSA/IAA systems (LP: #2163062)", " - SAUCE: dmaengine: idxd: Do not call destroy_workqueue with null idxd->wq", " - SAUCE: dmaengine: idxd: fix duplicate memory frees on initialization", " error path.", " * [HP][ZBook Power 16 G11] Laptop freezed after upgrading the BIOS", " (LP: #2132119)", " - PCI/ASPM: Avoid L0s for Realtek RTS525A", " * Fix noise of audio output on more Dell QCx1255 models after reboot", " (LP: #2163293)", " - ALSA: hda/realtek - Add quirk for Dell Pro QC1255", " * Fix no audio input/output device on Dell WCL Slate platform with", " CirrusLogic audio solution (LP: #2160200)", " - ASoC: SDCA: fix the register to ctl value conversion for Q7.8 format", " - ASoC: SOF: ipc4-control: Use local copy of IPC message for sending", " * Fix no audio output and mute hotkey not working on HP ZBook 8 G2a", " (LP: #2158858)", " - ALSA: hda/realtek: Add inverted LED quirk for HP ZBook 8 G2a", " * Dock ethernet stops working after Thunderbolt dock unplug on Dell systems", " (LP: #2162704)", " - usb: core: port: Deattach Type-C connector on component unbind", " * USB-C alt mode dropped with false firmware bug warning on Dell systems", " (LP: #2162695)", " - Revert \"usb: typec: ucsi: Detect and skip duplicate altmodes from buggy", " firmware\"", " - Revert \"usb: typec: ucsi: Add duplicate detection to nvidia registration", " path\"", " - Revert \"usb: typec: ucsi: yoga_c630: Remove redundant duplicate altmode", " handling\"", " - usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware", " - usb: typec: ucsi: Add duplicate detection to nvidia registration path", " - usb: typec: ucsi: yoga_c630: Remove redundant duplicate altmode handling", " * Resolute update: upstream stable patchset 2026-08-20 (LP: #2164666)", " - crypto: algif_skcipher - force synchronous processing", " - crypto: sun4i-ss - Remove insecure and unused rng_alg", " - [Config] Remove unused CRYPTO_DEV_SUN4I_SS_PRNG", " - media: uvcvideo: Fix deadlock if uvc_status_stop is called from", " async_ctrl.work", " - bpf: Clear delta when clearing reg id for non-{add,sub} ops", " - selftests/bpf: Add tests for delta tracking when src_reg == dst_reg", " - selftests/bpf: Add tests for stale delta leaking through id reassignment", " - ALSA: hda/realtek: Add quirk for TongFang X6xx45xU", " - ALSA: hda: conexant: Remove mic bias threshold override", " - ALSA: hda: Fix cached processing coefficient verbs", " - ALSA: hda/realtek: Fix speakers on Legion Pro 7 16ARX8H with codec SSID", " 17aa:38a7", " - media: uvcvideo: Use hw timestaming if the clock buffer is full", " - media: uvcvideo: Avoid partial metadata buffers", " - media: uvcvideo: Fix buffer sequence in frame gaps", " - media: uvcvideo: Fix dev_sof filtering in hw timestamp", " - media: uvcvideo: Do not add clock samples with small sof delta", " - media: uvcvideo: Relax the constrains for interpolating the hw clock", " - 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: max310x: implement gpio_chip::get_direction()", " - serial: 8250_omap: clear rx_running on zero-length DMA completes", " - rxrpc: rxrpc_verify_data ensure rx_dec_buffer alloc", " - rxrpc: Fix socket notification race", " - rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)", " - rxrpc: Fix potential infinite loop in rxrpc_recvmsg()", " - rxrpc: Fix rxrpc_rotate_tx_rotate() to check there's something to rotate", " - rxrpc: Fix oob challenge leak in cleanup after notification failure", " - rxrpc: Fix ACKALL packet handling", " - rxrpc: Fix the reception of a reply packet before data transmission", " - rxrpc: Fix leak of connection from OOB challenge", " - afs: fix NULL pointer dereference in afs_get_tree()", " - afs: handle CB.InitCallBackState3 requests without a server record", " - afs: Fix uncancelled rxrpc OOB message handler", " - fbcon: fix NULL pointer dereference for a console without vc_data", " - fbcon: Use correct type for vc_resize() return value", " - openrisc: mm: Fix section mismatch between map_page and __set_fixmap", " - clocksource/drivers/sun5i: Handle error returns from", " devm_reset_control_get_optional_exclusive()", " - accel/amdxdna: Fix leak when pinning ubuf pages", " - drm/rockchip: dw_dp: Switch to drmm_kzalloc()", " - drm/rockchip: dw_dp: Fix null-ptr-deref in dw_dp_remove()", " - drm/rockchip: Test for imported buffers with drm_gem_is_imported()", " - drm/tidss: Drop extra drm_mode_config_reset() call", " - drm/gpusvm: Reject VMAs with VM_IO or VM_PFNMAP when creating SVM ranges", " - drm/gpuvm: Do not prepare NULL objects", " - 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", " - selftests/bpf: Fix off-by-one in bpf_cpumask_populate related selftest", " - dt-bindings: timer: Remove sifive,fine-ctr-bits property", " - drm/amd/pm: remove trailing semicolon from AMDGPU_PM_POLICY_ATTR macro", " - selftests/bpf: Use local type for flow_offload_tuple_rhash in", " xdp_flowtable", " - selftests/bpf: Use local type for bpf_fou_encap in test_tunnel_kern", " - Documentation: proc: fix section numbering in table of contents", " - arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Cobra", " - arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S", " - arm64: dts: qcom: ipq5424: Fix USB simple_bus_reg warnings", " - arm64: dts: qcom: sc8180x: Fix phy simple_bus_reg warning", " - 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: fix wrong pci_get_drvdata type in AER handlers", " - wifi: rtw88: fix wrong pci_get_drvdata type in AER handlers", " - wifi: rtw89: Correct data type for scan index to avoid infinite loop", " - wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA", " buffer", " - wifi: rtw89: add bounds check on firmware mac_id in link lookup", " - kconfig: fix potential NULL pointer dereference in conf_askvalue", " - soc: xilinx: Shutdown and free rx mailbox channel", " - pinctrl: mediatek: eint: Drop base from mtk_eint_chip_write_mask()", " - wifi: ath9k: fix OOB access from firmware tx status queue ID", " - ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint", " - Documentation/rv: Replace stale website link", " - 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", " - memory: tegra: Wire up system sleep PM ops", " - crypto: qat - fix heartbeat error injection", " - lib/vsprintf: Fix to check field_width and precision", " - dts: spacemit: set console baud rate on bpif3", " - pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path", " - dt-bindings: vendor-prefixes: Add Displaytech Ltd.", " - drm/gpuvm: take refcount on DRM device", " - drm/panel: Clean up S6E3HA2 config dependencies and fill help text", " - ARM: dts: rockchip: Add #{address,size}-cells to Chromium-based", " /firmware", " - arm64: dts: rockchip: Add #{address,size}-cells to Chromium-based", " /firmware", " - arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc", " - arm64: dts: imx8x-colibri: Correct SODIMM PAD settings", " - Revert \"arm64: dts: imx8mm-kontron: Add support for reading SD_VSEL", " signal\"", " - Revert \"arm64: dts: imx8mp-kontron: Add support for reading SD_VSEL", " signal\"", " - drm: renesas: rz-du: mipi_dsi: Fix return path on error", " - alarmtimer: Remove stale return description from alarm_handle_timer()", " - OPP: Fix race between OPP addition and lookup", " - crypto: ccp - Reverse the cleanup order in psp_dev_destroy()", " - crypto: ccp - Fix snp_filter_reserved_mem_regions() off-by-one", " - 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", " - ARM: multi_v7_defconfig: Correct QCOM_RPMH and QCOM_RPMHPD", " - nilfs2: fix backing_dev_info reference leak", " - media: qcom: camss: vfe: fix PIX subdev naming on VFE lite", " - media: iris: scale MMCX power domain on SM8250", " - media: venus: scale MMCX power domain on SM8250", " - iommu/amd: Fix a stale comment about which legacy mode is user visible", " - soc: mediatek: mtk-mmsys: Restore MT8167 routing masks lost during merge", " - bpf: fix crash in bpf_[set|remove]_dentry_xattr for negative dentries", " - uaccess: fix ignored_trailing logic in copy_struct_to_user()", " - arm64: dts: mediatek: mt8192-asurada: Move PCIe DMA bounce buffer to", " host", " - rust: alloc: fix `Vec::extend_with` SAFETY comment", " - clk: scmi: Fix clock rate rounding", " - arm64: dts: qcom: kodiak: Fix ICE reg size", " - arm64: dts: qcom: sm8450: Fix ICE reg size", " - drm/hisilicon/hibmc: add updating link cap in DP detect()", " - drm/hisilicon/hibmc: fix no showing when no connectors connected", " - drm/hisilicon/hibmc: move display contrl config to hibmc_probe()", " - 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()", " - scsi: hisi_sas: Add slave_destroy interface for v3 hw", " - 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)", " - IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier", " - RDMA/hns: Fix arithmetic overflow in calc_hem_config()", " - RDMA/mlx5: Fix UMR XLT cleanup on ODP populate failure", " - RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference", " - RDMA/hns: Initialize seqfile before creating file", " - drm/syncobj: Fix memory leak in drm_syncobj_find_fence()", " - selftests/bpf: Reject unsupported -k option in vmtest.sh", " - selftests/bpf: Fix test for refinement of single-value tnum", " - iommu/arm-smmu-qcom: Fix fastrpc compatible string in ACTLR client match", " table", " - selftests/mm: Fix resv_sz when parsing arm64 signal frame", " - firmware: arm_ffa: Honor partition info descriptor size", " - arm64: dts: imx8dxl-evk: Remove unnecessary PCIe EP properties", " - arm64: dts: imx8qxp-mek: Remove unnecessary PCIe EP vpcie-supply", " - arm64: dts: imx95-19x19-evk: Fix PCIe EP vpcie-supply", " - media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()", " - media: atomisp: gc2235: fix UAF and memory leak", " - staging: media: atomisp: fix loop shadowing in ia_css_stream_destroy()", " - riscv: dts: spacemit: set console baud rate on Milk-V Jupiter", " - firmware: smccc: Fix Arm SMCCC SOC_ID name call", " - firmware: arm_scmi: Read sensor config as 32-bit value", " - sysfs: clamp show() return value in sysfs_kf_read()", " - bitops: use common function parameter names", " - regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions", " - tools/nolibc: getopt: Fix potential out of bounds access", " - nilfs2: Fix return in nilfs_mkdir", " - net/sched: sch_drr: annotate data-races around cl->deficit", " - media: rockchip: rga: fix too small buffer size", " - firmware: arm_scmi: Fix OOB in scmi_power_name_get()", " - arm64: dts: qcom: lemans: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: monaco: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sc7180: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: kodiak: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8550: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8750: Add power-domain and iface clk for ice node", " - tracing: Bound synthetic-field strings with seq_buf", " - arm64: dts: qcom: lemans: Add eDP ref clock for eDP PHYs", " - writeback: drop now-unnecessary rcu_barrier() in", " cgroup_writeback_umount()", " - kernfs: fix suspicious RCU usage in kernfs_put()", " - 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", " - Revert \"treewide: Fix probing of devices in DT overlays\"", " - of: dynamic: Fix overlayed devices not probing because of fw_devlink", " - crypto: eip93 - fix reset ring register definition", " - cpufreq: Documentation: fix sampling_down_factor range", " - cpufreq: conservative: Simplify frequency limit handling", " - pwm: imx27: Fix variable truncation in .apply()", " - RDMA/mana_ib: Use ib_get_eth_speed for reporting port speed", " - bus: sunxi-rsb: Always check register address validity", " - pinctrl: spacemit: fix NULL check in spacemit_pin_set_config", " - 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/hns: Fix log flood after cmd_mbox failure", " - RDMA/counter: Fix incorrect port index in rdma_counter_init() error", " cleanup", " - pinctrl: meson: amlogic-a4: fix gpio output glitch", " - PM: sleep: Use complete() in device_pm_sleep_init()", " - 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", " - driver core: Fix missing jiffies conversion in", " deferred_probe_extend_timeout()", " - driver core: Guard deferred probe timeout extension with", " delayed_work_pending()", " - mtd: spi-nor: debugfs: Fix the flags list", " - mtd: spi-nor: Drop duplicate Kconfig dependency", " - ALSA: xen-front: Reset event channel state on stream clear", " - ALSA: xen-front: Connect event channel after stream prepare", " - ALSA: seq: oss: Fix UAF at handling events with embedded SysEx data", " - ALSA: seq: midi: Serialize output teardown with event_input", " - selftests: Fix Makefile target for nsfs", " - pinctrl: nuvoton: ma35d1: fix MFP register offset and pin table", " - pinctrl: cs42l43: Fix leaked pm reference on error path", " - pinctrl: cs42l43: Fix polarity on debounce", " - init/initramfs_test: wait_for_initramfs() before running", " - nvmet-tcp: fix page fragment cache leak in error path", " - nvmet-tcp: check return value of nvmet_tcp_set_queue_sock", " - nvme-pci: fix out-of-bounds access in nvme_setup_descriptor_pools", " - 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", " - iommu/amd: Fix premature break in init_iommu_one()", " - rtla/actions: Restore continue flag in actions_perform()", " - 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", " - bpftool: Fix typo in struct_ops map FD generation for light skeleton", " - libbpf: Fix UAF in strset__add_str()", " - ARM: tegra: Add #{address,size}-cells to Chromium-based /firmware", " - arm64: tegra: Add #{address,size}-cells to Chromium-based /firmware", " - 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", " - crypto: inside-secure/eip93 - Add check for devm_request_threaded_irq", " - crypto: tegra - Fix dma_free_coherent size error", " - crypto: tegra - Return ENOMEM when input buffer allocation fails for ccm", " - sched/deadline: Reject debugfs dl_server writes for offline CPUs", " - drm/msm/dp: fix HPD state status bit shift value", " - drm/msm/dp: Fix the ISR_* enum values", " - EDAC/igen6: Fix call trace due to missing release()", " - EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in", " skx_get_dimm_info", " - arm64: dts: st: Fix SAI addresses on stm32mp251", " - RDMA/umem: Add ib_umem_is_contiguous() stub for", " !CONFIG_INFINIBAND_USER_MEM", " - RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe", " - RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path", " - Revert \"media: venus: hfi_platform: Correct supported codecs for sc7280\"", " - 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", " - amba: use generic driver_override infrastructure", " - cdx: use generic driver_override infrastructure", " - Drivers: hv: vmbus: use generic driver_override infrastructure", " - rpmsg: use generic driver_override infrastructure", " - raid1: fix nr_pending leak in REQ_ATOMIC bad-block error path", " - bpf: fix BPF_PROG_QUERY OOB write and cgroup backward compat", " - selftests/bpf: add verification for BPF_PROG_QUERY attr size boundaries", " - libbpf: Skip hash computation when loader generation failed", " - libbpf: Skip endianness swap when loader generation failed", " - ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data", " writeback", " - spi: atmel: fix DMA channel and bounce buffer leaks", " - ASoC: rsnd: Fix RSND_SOC_MASK width to single nibble", " - NFSD: Fix delegation reference leak in nfsd4_revoke_states", " - ARM: imx3: Fix CCM node reference leak", " - HID: wiimote: Fix table layout and whitespace errors", " - wifi: ath12k: fix incorrect HT/VHT/HE/EHT MCS reporting in monitor mode", " - wifi: ath12k: fix NULL deref in change_sta_links for unready link", " - ata: libata: Fix ata_exec_internal()", " - ARM: imx31: Fix IIM mapping leak in revision check", " - x86/cpu: Keep the PROCESSOR_SELECT menu together", " - nvdimm/btt: Handle preemption in BTT lane acquisition", " - scsi: Revert \"scsi: Fix sas_user_scan() to handle wildcard and multi-", " channel scans\"", " - bpf: Reject exclusive maps as inner maps in map-in-map", " - libbpf: Reject non-exclusive metadata maps in the signed loader", " - libbpf: Skip initial_value override on signed loaders", " - libbpf: Skip max_entries override on signed loaders", " - 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", " - driver core: Use system_percpu_wq instead of system_wq", " - bpf: Reject exclusive maps for bpf_map_elem iterators", " - tick/sched: Fix TOCTOU in nohz idle time fetch", " - lib/test_meminit: use && for bools", " - riscv: dts: sophgo: sg2044: use hex for CPU unit address", " - riscv: dts: sophgo: sg2042: use hex for CPU unit address", " - configfs_lookup(): don't leave ->s_dentry dangling on failure", " - lockdep/selftests: Restore migrate_disable() state on PREEMPT_RT", " - lockdep/selftests: Restore sched_rt_mutex state on PREEMPT_RT", " - ext4: fix fast commit wait/wake bit mapping on 64-bit", " - drm/amdgpu: set sub_block_index for mca ras sub-blocks", " - bpftool: Use libbpf error code for flow dissector query", " - vhost: fix vhost_get_avail_idx for a non empty ring", " - iommu/vt-d: Fix RB-tree corruption in probe error path", " - perf/x86/amd/core: Always use the NMI latency mitigation", " - perf/x86/intel/uncore: Fix discovery unit lookup for multi-die systems", " - perf/x86/amd/uncore: Use Node ID to identify DF and UMC domains", " - xfrm: fix NAT-related field inheritance in SA migration", " - cxl/fwctl: Fix __fortify_panic", " - drm/amdkfd: always resume_all after suspend_all", " - of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array()", " fails", " - ocfs2: rebase copied fsdlm LVB pointers in locking_state", " - lib: kunit_iov_iter: repeatedly call alloc_pages_bulk()", " - 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: 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", " - netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock", " - ALSA: usb-audio: qcom: Initialize offload control return value", " - x86/cpu: Remove obsolete aperfmperf_get_khz() declaration", " - netfilter: conntrack: revert ct extension genid infrastructure", " - netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper", " is pptp", " - RDMA/hfi1: Open-code rvt_set_ibdev_name()", " - IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()", " - ALSA: hda: fix Kconfig dependency of HD Audio PCI", " - RDMA/irdma: Fix OOB read during CQ MR registration", " - RDMA/irdma: Initialize iwmr->access during MR registration", " - arm64: dts: imx8mp-kontron: Reduce EERAM SPI clock frequency", " - arm64: dts: imx95: Correct PCIe outbound address space configuration", " - arm64: dts: lx2162a-clearfog: use rev2 SoC dtsi", " - arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio codec as", " well", " - arm64: dts: imx8mp-kontron: Fix GPIO for display power switch", " - bpf: Clear rb node linkage when freeing bpf_rb_root", " - bpf: Check tail zero of bpf_map_info", " - 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: cpu_ops: Change return value type of cpu_is_stopped() to bool", " - riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe", " - ALSA: seq: Clear variable event pointer on read", " - bpf: Fix NMI/tracepoint re-entry deadlock on lru locks", " - kunit:tool: Don't write to stdout when it should be disabled", " - powerpc/8xx: implement get_direction() in cpm1", " - bpf: Fix NULL pointer dereference in bpf_task_from_vpid()", " - ACPI: IPMI: Fix message kref handling on dead device", " - cpufreq: Documentation: fix conservative governor freq_step description", " - thermal: testing: reject missing command arguments", " - btrfs: don't force DIO writes to be serialized", " - IB/mlx5: Don't take the rereg_mr fallback without a new translation", " - IB/mlx5: Properly support implicit ODP rereg_mr", " - IB/mlx5: Remove unused mkc bits in mlx5r_umr_update_mr_page_shift()", " - IB/mlx5: Pull the pdn out of the depths of the umr machinery", " - IB/mlx5: Don't mangle the mr->pd inside the rereg callback", " - spi: ep93xx: fix double-free of zeropage on DMA setup failure", " - ASoC: amd: acp-sdw-legacy: Bound DAI link iteration", " - ASoC: amd: acp-sdw-sof: Bound DAI link iteration", " - firmware_loader: Fix recursive lock in device_cache_fw_images()", " - configfs: fix lockless traversals of ->s_children", " - watchdog: unregister PM notifier on watchdog unregister", " - pinctrl: qcom: Fix resolving register base address from device node", " - 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", " - ARM: configs: Drop duplicated CONFIG_EXT4_FS", " - wifi: mt76: mt7925: clean up DMA on probe failure", " - wifi: mt76: use kfree_rcu for offchannel link in mt76_put_vif_phy_link", " - wifi: mt76: mt7996: add missing max_remain_on_channel_duration", " - wifi: mt76: mt7925: fix stale pointer comparisons in change_vif_links", " - wifi: mt76: mt7925: keep TX BA state in the primary WCID", " - wifi: mt76: mt792x: skip MLD header rewrite for 802.3 encap TX", " - wifi: mt76: mt7925: validate skb length in testmode query", " - wifi: mt76: mt7996: Fix possible token leak in mt7996_tx_prepare_skb()", " - wifi: mt76: mt7996: Fix possible NULL pointer dereference in", " mt7996_mac_write_txwi_80211()", " - wifi: mt76: mt7996: fix reading zeroed info->control.flags after", " mt76_tx_status_skb_add()", " - wifi: mt76: mt7996: limit work in set_bitrate_mask", " - 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", " - wifi: mt76: mt7925: fix potential tx_retries underflow", " - wifi: mt76: mt7996: fix potential tx_retries underflow", " - btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()", " - ALSA: aloop: Drop superfluous break", " - gpio: mt7621: fix interrupt banks mapping on gpio chips", " - wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is", " reported", " - fbdev: sm501fb: Fix buffer errors in OF binding code", " - vfs: add FS_USERNS_DELEGATABLE flag and set it for NFS", " - hwmon: (it87) Clamp negative values to zero in set_fan()", " - btrfs: zoned: don't account data relocation space-info in statfs free", " space", " - Revert \"btrfs: fix the file offset calculation inside", " btrfs_decompress_buf2page()\"", " - btrfs: zoned: always set max_active_zones for zoned devices", " - btrfs: annotate lockless read of defrag_bytes in should_nocow()", " - btrfs: fix deadlock cloning inline extent when using flushoncommit", " - igc: skip RX timestamp header for frame preemption verification", " - ASoC: sma1307: Fix uevent string leaks in fault worker", " - IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified", " - NFSD: Handle layout stid in nfsd4_drop_revoked_stid()", " - 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", " - virtio: rtc: tear down old virtqueues before restore", " - virtio_console: read size from config space during device init", " - vduse: Requeue failed read to send_list head", " - tools/virtio: check mmap return value in vringh_test", " - vdpa/octeon_ep: Fix PF->VF mailbox data address calculation", " - vdpa/octeon_ep: fix IRQ-to-ring mapping in interrupt handler", " - ASoC: cs35l56: Fix missing calls to wm_adsp2_remove()", " - ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend fails", " - ext4: fix ERR_PTR(0) in ext4_mkdir()", " - tools: missed broadcast_neigh if_link uapi header", " - netlink: specs: rt-link: missed broadcast-neigh", " - bonding: 3ad: add lacp_strict configuration knob", " - bonding: 3ad: fix carrier when no usable slaves", " - 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()", " - vfio/qat: fix f_pos race in qat_vf_resume_write()", " - bpf: Tighten cgroup storage cookie checks for prog arrays", " - pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag", " - pinctrl: airoha: an7581: add missed gpio32 pin group", " - pinctrl: airoha: an7581: fix misprint in gpio19 pinconf", " - arm64: dts: allwinner: a523: Add missing GPIO interrupt", " - ASoC: cs35l56: Fix possible uninitialized value in", " cs35l56_spi_system_reset()", " - s390/process: Fix kernel thread function pointer type", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for", " non-serdev device", " - Bluetooth: eir: Fix stack OOB write when prepending the Flags AD", " - Bluetooth: hci_event: fix simultaneous discovery stuck in FINDING", " - Bluetooth: hci_core: Fix UAF in hci_unregister_dev()", " - Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path", " - Bluetooth: hci: validate codec capability element length", " - Bluetooth: vhci: validate devcoredump state before side effects", " - fs: efs: remove unneeded debug prints", " - RDMA/mlx5: Remove DCT restrack tracking", " - 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: SOF: Intel: hda-sdw-bpt: select SND_SOF_SOF_HDA_SDW_BPT properly", " - 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: dsa: qca8k: fix led devicename when using external mdio bus", " - 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", " - net: pfcp: allocate per-cpu tstats for PFCP netdevs", " - 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: Unregister cxl_acpi in cxl_test_init() error path", " - 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", " - ALSA: usb-audio: qcom: Guard sideband endpoint removal", " - ALSA: seq: Fix kernel heap address leak in bounce_error_event()", " - spi: xilinx: use FIFO occupancy register to determine buffer size", " - iommu: Avoid copying the user array twice in the full-array copy helper", " - 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", " - virtio_net: do not allow tunnel csum offload for non GSO packets", " - net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net/sched: sch_dualpi2: 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", " - net: watchdog: fix refcount tracking races", " - net: ethernet: mtk_wed: fix loading WO firmware for MT7986", " - net/sched: sch_dualpi2: Add missing module alias", " - bpf: Run generic devmap egress prog on private skb", " - net/mlx5: Check max_macs devlink param value against max capability", " - bpf: Fix setting retval to -EPERM for cgroup hooks not returning errno", " - octeontx2-af: npc: Fix size of entry2cntr_map", " - net: ethernet: mtk_wed: debugfs: correct index in wed_amsdu_show()", " - net: wwan: t7xx: check skb_clone in control TX", " - 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", " - net: bcmgenet: Use weighted round-robin TX DMA arbitration", " - net: airoha: Fix register index for Tx-fwd counter configuration", " - net: airoha: Fix debugfs new-tuple display for IPv4 ROUTE entries", " - kcm: use WRITE_ONCE() when changing lower socket callbacks", " - ALSA: seq: oss: Serialize readq reset state with q->lock", " - ALSA: seq: avoid stale FIFO cells during resize", " - 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: Fix typo in verify_umulti_link_info", " - selftests/bpf: Initialize operation name before use", " - bpf: Fix bpf_get/setsockopt to tos for ipv4-mapped ipv6 socket", " - udf: fix nls leak on udf_fill_super() failure", " - bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()", " - net: remove addr_len argument of recvmsg() handlers", " - sockmap: Fix use-after-free in udp_bpf_recvmsg()", " - 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", " - tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)", " - net: airoha: Fix always-true condition in PPE1 queue reservation loop", " - net: ethernet: oa_tc6: Remove FCS size in RX frame", " - ionic: Fix check in ionic_get_link_ext_stats", " - RDMA/bnxt_re: Free SRQ toggle page after firmware teardown", " - RDMA/bnxt_re: Avoid displaying the kernel pointer", " - RDMA/bnxt_re: Fail DBR related page allocation UAPIs if the feature is", " disabled", " - ksmbd: fix use-after-free in same_client_has_lease()", " - mfd: rsmu: Fix page register setup", " - mfd: cs42l43: Sanity check firmware size", " - ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write", " - 9p: avoid returning ERR_PTR(0) from mkdir operations", " - eventpoll: rename ep_remove_safe() back to ep_remove()", " - eventpoll: expand top-of-file overview / locking doc", " - eventpoll: rename attach_epitem() to ep_attach_file()", " - 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", " - i3c: master: svc: Fix missed IBI after false SLVSTART on NPCM845", " - staging: nvec: fix use-after-free in nvec_rx_completed()", " - perf debuginfo: Fix libdw API contract violations", " - coresight: cti: Fix DT filter signals silently ignored", " - soundwire: don't program SDW_SCP_BUSCLOCK_SCALE on a unattached", " Peripheral", " - soundwire: fix bug in sdw_add_element_group_count found by syzkaller", " - coresight: ete: Always save state on power down", " - 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", " - perf sched: Add missing mmap2 handler in timehist", " - PCI: loongson: Do not ignore downstream devices on external bridges", " - rust: alloc: fix assert in `Vec::reserve` doc test", " - bus: mhi: ep: Fix potential deadlock in mhi_ep_reset_worker()", " - coresight: fix missing error code when trace ID is invalid", " - clk: qcom: cmnpll: Account for reference clock divider", " - phy: phy-can-transceiver: Check driver match and driver data against", " NULL", " - perf pmu: Skip test on Arm64 when #slots is zero", " - clk: at91: sam9x7: Fix gmac_gclk clock definition", " - soundwire: intel_ace2x: release bpt_stream when close it", " - coresight: Fix source not disabled on idr_alloc_u32 failure", " - mailbox: mpfs: fix check for syscon presence in mpfs_mbox_inbox_isr()", " - mailbox: mtk-adsp: fix UAF during device teardown", " - PCI: dwc: Fix signedness bug in fault injection test code", " - perf build-id: Fix off-by-one bug when printing kernel/module build-id", " - 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", " - perf test amd ibs: Fix incorrect kernel version check", " - gpib: Fix inappropriate ioctl error return", " - char: tlclk: fix use-after-free in tlclk_cleanup()", " - gpib: fix double decrement of descriptor_busy in command_ioctl()", " - clk: renesas: rzg2l: Rename iterator in for_each_mod_clock() to avoid", " shadowing", " - powerpc tools perf: Initialize error code in auxtrace_record_init", " function", " - PCI: qcom: Disable ASPM L0s for SA8775P", " - perf header: Sanity check HEADER_EVENT_DESC attr.size before swap", " - 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", " - drm/amd/display: Add missing kdoc for ALLM parameters", " - thunderbolt: debugfs: Fix margining error counter buffer leak", " - dmaengine: imx-sdma: Refine spba bus searching in probe", " - dt-bindings: dma: nvidia,tegra186-gpc-dma: Make reset optional", " - perf: Fix off-by-one stack buffer overflow in kallsyms__parse()", " - perf annotate: Fix crashes on empty annotate windows", " - perf tools: Guard test_bit from out-of-bounds sample CPU", " - perf sched: Fix thread reference leak in latency_switch_event", " - perf tools: Add bounds check to cpu__get_node()", " - perf sched: Cap max_cpu at MAX_CPUS in timehist sample processing", " - perf sched: Fix register_pid() overflow, strcpy, and BUG_ON", " - perf mmap: Guard cpu__get_node() return in aio_bind()", " - perf stat: Bounds-check CPU index in topology aggregation callbacks", " - perf c2c: Bounds-check CPU and node IDs before bitmap and array access", " - perf c2c: Bounds-check CPU IDs in setup_nodes() topology loop", " - perf sched: Clean up idle_threads entry on init failure", " - perf sched: Use thread__put() in free_idle_threads()", " - perf sched: Replace BUG_ON and add NULL checks in replay event helpers", " - perf mmap: Fix NULL deref in aio cleanup on alloc failure", " - perf stat: Introduce perf_env__get_cpu_topology() to guard NULL env->cpu", " - perf c2c: Fix use-after-free in he__get_c2c_hists() error path", " - perf timechart: Fix cpu2y() OOB read on untrusted CPU index", " - perf tools: Fix int16_t truncation of max_cpu_num in set_max_cpu_num()", " - dt-bindings: clock: qcom: Add X1P42100 camera clock controller", " - clk: qcom: camcc-x1e80100: Add support for camera QDSS debug clocks", " - mshv: add bounds check on vp_index in mshv_intercept_isr()", " - dmaengine: qcom: gpi: set DMA_PRIVATE capability", " - dmaengine: Fix possible use after free", " - dmaengine: dma-axi-dmac: Properly free struct axi_dmac_desc", " - dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor", " - clk: qcom: a53: Corrected frequency multiplier for 1152MHz", " - sunrpc: Fix error handling in rpc_sysfs_xprt_switch_add_xprt_store()", " - pNFS/filelayout: fix cheking if a layout is striped", " - 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", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in", " pg_get_mirror_count_write", " - PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro", " - pwm: rzg2l-gpt: Add missing newlines to dev_err_probe() messages", " - PCI: meson: Propagate devm_add_action_or_reset() failure", " - PCI: meson: Add missing remove callback", " - fs/ntfs3: resize log->one_page_buf when adopting on-disk page size", " - platform/x86/intel/vsec: Decouple add/link helpers from PCI", " - platform/x86/intel/vsec: Switch exported helpers from pci_dev to device", " - platform/x86/intel/vsec: Return real error codes from registration path", " - platform/x86/intel/vsec: Restore BAR fallback for header walk", " - perf tools: Fix get_max_num() size_t underflow on empty sysfs file", " - perf tools: Use scnprintf() in cpu_map__snprint() to prevent overflow", " - perf tools: Use perf_env__get_cpu_topology() in machine__resolve()", " - PCI: rcar-host: Remove unused LIST_HEAD(res)", " - perf sched: Bounds-check prio before test_bit() in timehist", " - perf sched: Fix idle-hist callchain display using wrong rb_first variant", " - perf bpf: Use scnprintf() in snprintf_hex() and", " synthesize_bpf_prog_name()", " - perf hists: Fix snprintf() in hists__scnprintf_title() UID filter path", " - xprtrdma: Fix ep kref imbalance on ADDR_CHANGE", " - xprtrdma: Initialize re_id before removal registration", " - xprtrdma: Check frwr_wp_create() during connect", " - xprtrdma: Document and assert reply-handler invariants", " - xprtrdma: Resize reply buffers before reposting receives", " - xprtrdma: Sanitize the reply credit grant after parsing", " - xprtrdma: Repost Receive buffers for malformed replies", " - xprtrdma: Return sendctx slot after Send preparation failure", " - perf s390: Fix TEXTREL in Python extension by compiling as PIC", " - perf cs-etm: Queue context packets for frontend", " - perf pmu: Fix pmu_id() heap underwrite on empty identifier file", " - perf pmu: Fix perf_pmu__parse_scale/unit() OOB access on empty sysfs", " file", " - tools lib api: Fix missing null termination in filename__read_int/ull()", " - perf symbols: Fix signed overflow in sysfs__read_build_id() size check", " - perf symbols: Bounds-check .gnu_debuglink section data", " - perf intel-pt: Fix snprintf size tracking bug in insn decoder", " - perf tools: Fix thread__set_comm_from_proc() on empty comm file", " - perf hwmon: Fix off-by-one null termination on sysfs reads", " - perf hwmon: Use scnprintf() in hwmon_pmu__for_each_event()", " - perf hwmon: Fix parse_hwmon_filename() strlcpy buffer overflow", " - perf symbols: Bounds-check descsz in sysfs__read_build_id() GNU fallback", " - perf hwmon: Guard label read against empty or failed reads", " - perf tools: Use snprintf() in dso__read_running_kernel_build_id()", " - tools lib api: Fix filename__write_int() writing uninitialized stack", " data", " - tools lib api: Fix mount_overload() snprintf truncation and toupper", " range", " - perf bpf: Add NULL check for btf__type_by_id() in", " synthesize_bpf_prog_name()", " - perf bpf: Fix map data leak in bpf_metadata_create() on alloc failure", " - perf bpf: Fix metadata leak in perf_env__add_bpf_info() on duplicate", " insert", " - perf symbols: Add bounds checks to elf_read_build_id() note iteration", " - perf symbols: Add bounds checks to read_build_id() note iteration in", " minimal build", " - dt-bindings: phy: sc8280xp-qmp-pcie: Disallow bifurcation register on", " Purwa", " - PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()", " - PCI: mediatek: Use actual physical address instead of virt_to_phys()", " - phy: freescale: phy-fsl-imx8qm-lvds-phy: Fix missing", " pm_runtime_disable() on probe error path", " - PCI: dwc: Avoid dwc_pcie_rasdes_debugfs_deinit() NULL dereference when", " no RAS DES capability", " - Revert \"PCI/MSI: Unmap MSI-X region on error\"", " - apparmor: fix shadowing of plabel that prevents cache from being updated", " - apparmor: fix race in unix socket mediation when peer_path is used", " - apparmor: fix refcount leak when updating the sk_ctx", " - security/apparmor/apparmorfs.c: conditionally compile", " get_loaddata_common_ref()", " - apparmor: check label build before no_new_privs test", " - apparmor: aa_label_alloc use aa_label_free on alloc failure", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [41/57]: apparmor-next 7.1:", " apparmor: fix rawdata_f_data implicit flex array\"", " - apparmor: fix rawdata_f_data implicit flex array", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [38/57]: apparmor-next 7.1:", " apparmor: grab ns lock and refresh when looking up changehat child", " profiles\"", " - apparmor: grab ns lock and refresh when looking up changehat child", " profiles", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [44/57]: apparmor-next 7.1:", " apparmor: fix potential UAF in aa_replace_profiles\"", " - apparmor: fix potential UAF in aa_replace_profiles", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor: fix NULL pointer dereference in", " unpack_pdb\"", " - apparmor: fix NULL pointer dereference in unpack_pdb", " - apparmor: remove or add symlinks to rawdata according to export_binary", " - apparmor: Fix return in ns_mkdir_op", " - apparmor: fail policy unpack on accept2 allocation failure", " - apparmor: aa_getprocattr free procattr leak on format failure", " - apparmor: put secmark label after secid lookup", " - apparmor: don't audit files pointing to aa_null.dentry", " - apparmor: fix uninitialised pointer passed to", " audit_log_untrustedstring()", " - i3c: mipi-i3c-hci: Preserve RUN bit when aborting DMA ring", " - i3c: master: Make hot-join workqueue freezable to block hot-join during", " suspend", " - i3c: master: Move rstdaa error suppression", " - i3c: master: Consolidate Hot-Join DAA work in the core", " - i3c: master: Ensure Hot-Join operations are stopped on shutdown", " - i3c: master: Defer new-device registration out of DAA caller context", " - i3c: master: Prevent reuse of dynamic address on device add failure", " - apparmor: fix label can not be immediately before a declaration", " - accel/ivpu: fix HWS command queue leak on registration failure", " - sparc: led: avoid trimming a newline from empty writes", " - perf symbols: Fix bswap copy-paste error for 32-bit ELF p_filesz", " - perf symbols: Validate p_filesz before use in filename__read_build_id()", " - perf symbols: Break infinite loop on zero-filled notes in", " sysfs__read_build_id()", " - perf tools: Add O_CLOEXEC to open() calls in DSO and ELF code", " - perf tools: Fix uninitialized pathname on uncompressed fallback in", " filename__decompress()", " - perf dso: Fix heap overflow in dso__get_filename() on decompressed path", " - perf dso: Set error code when open() fails on uncompressed fallback path", " - perf tools: Use snprintf() for root_dir path construction", " - perf hwmon: Fix fd check to accept fd 0 in hwmon_pmu__describe_items()", " - perf sched: Replace (void*)1 sentinel with proper runtime allocation", " - perf bpf: Validate func_info_rec_size and sub_id in", " synthesize_bpf_prog_name()", " - perf bpf: Reject oversized BPF metadata events that truncate header.size", " - perf bpf: Bounds-check array offsets in bpil_offs_to_addr()", " - perf cs-etm: Reject CPU IDs that would overflow signed comparison", " - gpio: mlxbf3: fail probe if gpiochip registration fails", " - drm/i915: clear CRTC color blob pointers after dropping refs", " - drm/xe: Fix wa_oob codegen recipe for external module builds", " - spi: dw: fix wrong BAUDR setting after resume", " - i3c: master: Update dev_nack_retry_count under maintenance lock", " - i3c: master: Add missing runtime PM get in dev_nack_retry_count_store()", " - ALSA: usb-audio: qcom: Free sideband sg_table objects", " - xfrm: annotate data-races around xfrm_policy_count[] and", " xfrm_policy_default[]", " - xfrm: validate selector family and prefixlen during match", " - perf machine: Use snprintf() for guestmount path construction", " - perf cs-etm: Validate num_cpu before metadata allocation", " - perf cs-etm: Require full global header in auxtrace_info size check", " - perf cs-etm: Bounds-check CPU in cs_etm__get_queue()", " - perf bpf: Validate array presence before casting BPF prog info pointers", " - perf dso: Set standard errno on decompression failure", " - ASoC: tlv320aic3x: restrict CLKDIV bypass Q values in dual-rate mode", " - drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free", " - drm/amd/display: Fix mem_type change detection for async flips", " - drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm", " - drm/amdgpu: initialize irq.lock spinlock earlier", " - 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", " - ALSA: usb-audio: qcom: reject stream disable with no active interface", " - ALSA: usb-audio: qcom: clear opened when stream enable fails", " - 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()", " - dpaa2-switch: fix VLAN upper check not rejecting bridge join", " - devlink: Fix parent ref leak in devl_rate_node_create()", " - devlink: Fix parent ref leak on tc-bw failure", " - net: airoha: fix foe_check_time allocation size", " - net: macb: add TX stall timeout callback to recover from lost TSTART", " write", " - flow_dissector: check device type before reading ETH_ADDRS", " - selftests: vlan_bridge_binding: Fix flaky operational state check", " - 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: Restore initial state on failed device_rename() in", " cfg802154_switch_netns()", " - ieee802154: Avoid calling WARN_ON() on -ENOMEM in", " cfg802154_switch_netns()", " - ieee802154: Remove WARN_ON() in cfg802154_pernet_exit()", " - ieee802154: fix kernel-infoleak in dgram_recvmsg()", " - mac802154: Prevent overwrite return code in", " mac802154_perform_association()", " - md/raid1: honor REQ_NOWAIT when waiting for behind writes", " - md/raid1: free r1_bio when REQ_NOWAIT is set and read would block on", " retry", " - netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()", " - netfilter: ipset: make sure gc is properly stopped", " - netfilter: nft_payload: reject offsets exceeding 65535 bytes", " - netfilter: nft_meta_bridge: add validate callback for get operations", " - netfilter: nft_flow_offload: zero device address for non-ether case", " - netfilter: nf_reject: skip iphdr options when looking for icmp header", " - netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak", " - mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()", " - irqchip/crossbar: Fix parent domain resource leak", " - alloc_tag: fix use-after-free in /proc/allocinfo after module unload", " - selftests/mm: restore default nr_hugepages value via exit trap in", " charge_reserved_hugetlb.sh", " - selftests/mm: restore default nr_hugepages value via exit trap in", " hugetlb_reparenting_test.sh", " - selftests/mm: fix hugetlb pathname construction in", " hugetlb_reparenting_test.sh", " - selftests/mm: fix cgroup task placement and drop memory.current checks", " in hugetlb_reparenting_test.sh", " - selftests/mm: size tmpfs according to PMD page size in", " split_huge_page_test", " - selftests/mm: free dynamically allocated PMD-sized buffers in", " split_huge_page_test", " - selftest/mm: register existing mapping with userfaultfd in hugetlb-", " mremap", " - selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap", " - selftests/mm: skip uffd-stress test when nr_pages_per_cpu is zero", " - 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", " - net: emac: Fix NULL pointer dereference in emac_probe", " - net/sched: act_ct: fix nf_connlabels leak on two error paths", " - net: airoha: Fix skb->priority underflow in airoha_dev_select_queue()", " - ipv6: ndisc: fix NULL deref in accept_untracked_na()", " - dpaa2-switch: do not accept VLAN uppers while bridged", " - 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", " - bpftool: Fix vmlinux BTF leak in cgroup commands", " - bpf: zero-initialize the fib lookup flow struct", " - bpf: Fix effective prog array index with BPF_F_PREORDER", " - power: sequencing: fix ABBA deadlock in pwrseq_device_unregister()", " - gpiolib: initialize return value in gpiochip_set_multiple()", " - 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()", " - ice: call netif_keep_dst() once when entering switchdev mode", " - rtc: isl1208: Balance enable_irq_wake() with disable_irq_wake() on", " cleanup", " - 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", " - i40e: Fix i40e_debug() to use struct i40e_hw argument", " - rtc: msc313: fix NULL deref in shared IRQ handler at probe", " - ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().", " - eth: bnxt: rename ring_err_stats -> ring_drv_stats", " - eth: bnxt: improve the timing of stats", " - ipv4: fib: Don't ignore error route in local/main tables.", " - md/raid5: use stripe state snapshot in break_stripe_batch_list()", " - md/raid5: avoid R5_Overlap races while breaking stripe batches", " - 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", " - gpio: davinci: fix IRQ domain leak on devm_kzalloc failure", " - 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: do not acquire dev->tx_global_lock in netdev_watchdog_up()", " - net: dsa: sja1105: round up PTP perout pin duration", " - veth: fix NAPI leak in XDP enable error path", " - net: usb: lan78xx: restore VLAN and hash filters after link up", " - 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", " - ipv6: fix state corruption during proxy_ndp sysctl restart", " - ipv6: fix missing notification for ignore_routes_with_linkdown", " - eth: fbnic: fix ordering of heartbeat vs ownership", " - thermal: testing: zone: Flush work items during cleanup", " - ACPI: processor_idle: Mark LPI enter functions as __cpuidle", " - 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: dsa: realtek: fix memory leak in rtl8366rb_setup_led()", " - net: phy: realtek: Clear MDIO_AN_10GBT_CTRL_ADV10G bit", " - octeontx2-af: Validate NIX maximum LFs correctly", " - 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", " - LoongArch: Move struct kimage forward declaration before use", " - LoongArch: BPF: Fix outdated tail call comments", " - LoongArch: BPF: Fix off-by-one error in tail call", " - ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count", " - net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync", " - dt-bindings: net: renesas,ether: Drop example \"ethernet-phy-", " ieee802.3-c22\" fallback", " - selftests: tls: size splice_short pipe by page size", " - 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", " - ALSA: FCP: Fix NULL pointer dereference in interface lookup", " - tracing: probes: fix typo in a log message", " - spi: sh-msiof: abort transfers when reset times out", " - ACPI: RIMT: Only defer the IOMMU configuration in init stage", " - riscv: Fix 32-bit call_on_irq_stack() frame pointer ABI", " - gpio: mvebu: fail probe if gpiochip registration fails", " - gpio: htc-egpio: use managed gpiochip registration", " - net: pse-pd: scope pse_control regulator handle to kref lifetime", " - seg6: validate SRH length before reading fixed fields", " - qede: fix out-of-bounds check for cqe->len_list[]", " - sctp: fix SCTP_RESET_STREAMS stream list length limit", " - MIPS: DEC: Ensure RTC platform device deregistration upon failure", " - MIPS: mm: Add check for highmem before removing memory block", " - ASoC: codecs: lpass-va-macro: Fix LPASS Codec Version for SC7280", " - hwmon: adm1275: Prevent reading uninitialized stack", " - hwmon: (pmbus) Fix passing events to regulator core", " - hwmon: (aspeed-g6-pwm-tach) Guard fan RPM calculation against divide-by-", " zero", " - ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump", " - usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()", " - net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy", " - net: libwx: fix VMDQ mask for 1-queue mode", " - 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", " - drm/panthor: Fix potential invalid pointer deref in", " group_process_tiler_oom()", " - drm/panthor: Don't overrule pending immediate ticks in", " sched_resume_tick()", " - drm/panthor: Fix a leak when a group is evicted before the tiler OOM is", " serviced", " - drm/panthor: Interrupt group start/resumption if group_bind_locked()", " fails", " - tracing/eprobes: Allow use of BTF names to dereference pointers", " - tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg", " - tracing/events: Fix to check the simple_tsk_fn creation", " - tracing: eprobe: read the complete FILTER_PTR_STRING pointer", " - tracing/fprobe: Fix NULL pointer dereference in fprobe_fgraph_entry()", " - tracing/probes: Make the $ prefix mandatory for comm access", " - irqchip/gic-v3-its: Fix OF node reference leak", " - irqchip/ts4800: Fix missing chained handler cleanup on remove", " - sctp: fix addr_wq_timer race in sctp_free_addr_wq()", " - virtio_net: disable cb when NAPI is busy-polled", " - cxgb4: Fix decode strings dump for T6 adapters", " - selftests: drv-net: tso: don't touch dangerous feature bits", " - 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: dualpi2: clear stale classification on filter miss", " - 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: Fix double netfs initialisation in afs_root_iget()", " - afs: use kvfree() to free memory allocated by kvcalloc()", " - afs: Remove erroneous seq |= 1 in volume lookup loop", " - afs: Fix bulk lookup malfunction due to change in dir_emit() API", " - afs: Fix misplaced inc of net->cells_outstanding", " - afs: Fix reinitialisation of the inode, in particular ->lock_work", " - afs: Fix callback service message parsers to pass through -EAGAIN", " - afs: Fix missing NULL pointer check in afs_break_some_callbacks()", " - afs: Fix vllist leak", " - afs: Fix lack of locking around modifications of net->cells_dyn_ino", " - afs: Fix premature cell exposure through /afs", " - 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", " - ovl: fix comment about locking order", " - iomap: guard io_size EOF trim against concurrent truncate underflow", " - netfs: Fix writethrough to use collection offload", " - netfs: Fix writeback error handling", " - netfs: Fix folio state after ENOMEM whilst under writeback iteration", " - drm/xe/pt: Fix NULL pointer dereference in xe_pt_zap_ptes_entry()", " - drm/xe/userptr: Hold notifier_lock for write on inject test path", " - drm/xe/hw_engine: Fix double-free of managed BO in error path", " - drm/xe/pf: Don't attempt to process FAST_REQ or EVENT relays", " - x86/uprobes: Keep shadow stack in sync for emulated CALLs", " - uprobes/x86: Use proper mm_struct in __in_uprobe_trampoline", " - cifs: Fix missing credit release on failure in cifs_issue_read()", " - ata: sata_gemini: unwind clocks on IDE pinctrl errors", " - ata: libata-scsi: limit simulated SCSI command copy to response length", " - 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: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()", " - HID: bpf: Fix hid_bpf_get_data() range check", " - selftests/hid: Load only requested struct_ops maps", " - selftests/hid: Cover hid_bpf_get_data() size overflow", " - arm64/sysreg: Fix BWE field encoding in ID_AA64DFR2_EL1", " - net: usb: net1080: validate packet_len before pad-byte access in", " rx_fixup", " - netfilter: xt_u32: reject invalid shift counts", " - netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()", " - netfilter: nft_set_rbtree: get command skips end element with open", " interval", " - netfilter: xt_connmark: reject invalid shift parameters", " - net/mlx5: LAG, MPESW, Fix missing complete() on devcom error", " - net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation", " - net/mlx5e: Fix HV VHCA stats agent registration race", " - net/mlx5e: Fix publication race for priv->channel_stats[]", " - net: microchip: vcap: fix races on the shared Super VCAP block", " - net: qualcomm: rmnet: validate MAP frame length before ingress parsing", " - net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload", " - 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: sco: Fix a race condition in sco_sock_timeout()", " - Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length", " - Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()", " - Bluetooth: L2CAP: fix tx ident leak for commands without a response", " - ring-buffer: Fix event length with forced 8-byte alignment", " - accel/amdxdna: Use unsigned long for nr_pages in amdxdna_hmm_register()", " - net/tls: Consume empty data records in tls_sw_read_sock()", " - net: usb: lan78xx: disable VLAN filter in promiscuous mode", " - gpio: dwapb: reduce allocation to single kzalloc", " - gpio: dwapb: Defer clock gating until noirq", " - tracing: Make tracepoint_printk static as not exported", " - accel/amdxdna: Fix potential amdxdna_umap lifetime race", " - drm/v3d: Reject invalid indirect BO handle in indirect CSD setup", " - net: mdio: select REGMAP_MMIO instead of depending on it", " - net/sched: cake: reject overhead values that underflow length", " - octeontx2-pf: check DMAC extraction support before filtering", " - perf/x86/amd/core: Avoid enabling BRS from the SVM reload path", " - gpio: mvebu: free generic chips on unbind", " - ipv4: igmp: annotate data-races around im->users", " - ipv4: igmp: annotate data-races around timer-related fields", " - ipv4: igmp: Fix potential memory leaks in igmp_mod_timer() and", " igmp_stop_timer()", " - ipvs: pass parsed transport offset to state handlers", " - ipvs: use parsed transport offset in TCP state lookup", " - s390/zcrypt: Remove the empty file", " - SUNRPC: release lower rpc_clnt if killed waiting for XPRT_LOCKED", " - 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", " - drm/xe: remove duplicate include", " - smb: client: fix overflow in passthrough ioctl bounds check", " - idpf: add padding to PTP virtchnl structures", " - 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", " - octeontx2-pf: clear stale mailbox IRQ state before request_irq()", " - octeontx2-vf: clear stale mailbox IRQ state before request_irq()", " - arm64: fpsimd: Fix type mismatch in sve_{save,load}_state()", " - arm64: dts: s32g3: Fix SWT8 watchdog address", " - ARM: dts: imx6ul-var-som: fix warning for non-existent dc-supply", " property", " - arm64: dts: qcom: sdm630: describe adsp_mem region properly", " - arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Ringneck", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix ADC sampling times", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move divergent mecio1 ADC", " channels to board files", " - arm64: dts: ti: k3-am62a7-sk: Add bootph-all tag to vqmmc", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Enable internal ADC reference", " - arm64: dts: imx8ulp-evk: Correct Type-C int GPIO flags", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix GPIO names typo", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move gpio-line-names to board", " files", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix expander gpio line typo", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move expander gpio-line-names to", " board files", " - LoongArch: KVM: Validate irqchip index in irqfd routing", " - 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()", " - powerpc/pseries/Kconfig: Enable CONFIG_VPA_PMU to be used with KVM", " - KVM: s390: pci: Fix GISC refcount leak on AIF enable failure", " - KVM: s390: pci: Fix handling of AIF enable without AISB", " - KVM: SEV: Do not allow intra-host migration/mirroring of SNP VMs", " - KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs", " - KVM: x86: Nullify irqfd->producer if updating IRTE for bypass fails", " - KVM: nVMX: Put vmcs12 pages if nested VM-Enter fails due to invalid", " guest state", " - KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers", " - KVM: arm64: nv: Drop bogus WARN for write to ZCR_EL2", " - KVM: arm64: nv: Write ESR_EL2 for injected nested SError exceptions", " - KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()", " - 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: efifb: fix memory leak in efifb_probe()", " - 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: Check runtime resume during probe", " - ASoC: mediatek: mt8192: Release reserved memory on cleanup", " - ASoC: mediatek: mt8183: Check runtime resume during probe", " - 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: nft_set_pipapo: don't leak bad clone into future transaction", " - 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", " - selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()", " - selinux: fix incorrect execmem checks on overlayfs", " - 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/brs: Fix kernel address leakage", " - perf/x86/amd/lbr: Fix kernel address leakage", " - cpufreq: schedutil: Fix uncleared need_freq_update on the .adjust_perf()", " path", " - cpufreq: intel_pstate: Set non-turbo capacity to HWP_GUARANTEED_PERF()", " - 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: retrieve ethhdr after potential skb realloc on RX", " - 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: ensure minimal ethernet header on TX", " - 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: clean untagged VLAN on netdev registration failure", " - batman-adv: frag: fix primary_if leak on failed linearization", " - batman-adv: mcast: avoid OOB read of num_dests header", " - 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", " - lockd: Plug nlm_file leak when nlm_do_fopen() fails", " - lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure", " - 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()", " - mm/mm_init: fix pageblock migratetype for ZONE_DEVICE compound pages", " - power: supply: cpcap-battery: Fix missing nvmem_device_put() causing", " reference leak", " - power: supply: max17042: fix OF node reference imbalance", " - mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch", " - mm/memory_hotplug: fix incorrect altmap passing in error path", " - 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: bound NTFS_DE view.data_off in", " UpdateRecordData{Root,Allocation}", " - ntfs3: cap RESTART_TABLE free-chain walker at rt->used", " - ntfs3: fix out-of-bounds read in decompress_lznt", " - landlock: Fix LANDLOCK_SCOPE_SIGNAL bypass on the SIGIO path", " - power: supply: charger-manager: fix refcount leak in is_full_charged()", " - selftests/landlock: Test SCOPE_SIGNAL on the SIGIO/fowner pgid path", " - 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", " - 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()", " - proc: only bump parent nlink when registering directories", " - fs/proc: fix KPF_KSM reported for all anonymous pages", " - powerpc/dt_cpu_ftrs: Set CPU_FTR_P11_PVR for Power11 and later", " processors", " - mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE", " - kcov: use WRITE_ONCE() for selftest mode stores", " - mtd: slram: remove failed entries from the device list", " - 9p: skip nlink update in cacheless mode to fix WARN_ON", " - power: supply: bq257xx: Fix VSYSMIN clamping logic", " - scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()", " - scsi: sas: Skip opt_sectors when DMA reports no real optimization hint", " - openrisc: Add full instruction cache invalidate functions", " - 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: fix UBSAN array-index-out-of-bounds in ocfs2_sum_rightmost_rec", " - 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: host: pci_generic: Fix the physical function check", " - 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()", " - s390/pkey: Check length in PKEY_VERIFYPROTK ioctl", " - s390/pkey: Check length in pkey_pckmo handler implementation", " - mtd: spi-nor: swp: Improve locking user experience", " - mtd: spi-nor: spansion: use die erase for multi-die devices only", " - mtd: rawnand: Pause continuous reads at block boundaries", " - openrisc: Fix jump_label smp syncing", " - mtd: maps: vmu-flash: fix NULL pointer dereference in initialization", " - taskstats: retain dead thread stats in TGID queries", " - irqchip/crossbar: Use correct index in crossbar_domain_free()", " - tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()", " - tpm: tpm2-sessions: wait for async KPP completion in tpm_buf_append_salt", " - sunrpc: fix uninitialized xprt_create_args structure", " - dmaengine: tegra: Fix burst size calculation", " - dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and", " ABORT_INT_MASK", " - platform/x86: dell-laptop: fix missing cleanups in init error path", " - platform/x86: ISST: Restore SST-PP control to all domains", " - 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", " - platform/x86/amd/pmc: Don't log during intermediate wakeups", " - pkey: Move keytype check from pkey api to handler", " - 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", " - hwmon: (max6697) add missing 'select REGMAP_I2C' to Kconfig", " - i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)", " - i2c: imx: fix locked bus on SMBus block-read of 0 (IRQ)", " - i2c: mediatek: fix WRRD for SoCs without auto_restart option", " - i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()", " - i2c: spacemit: fix spurious IRQ handling returning IRQ_HANDLED", " - ice: fix ice_init_link() error return preventing probe", " - tcp: Decrement tcp_md5_needed static branch", " - ufs: core: tracing: Do not dereference pointers in TP_printk()", " - xen/gntdev: fix error handling in ioctl", " - xfrm: use compat translator only for u64 alignment mismatch", " - 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()", " - NFS: Charge unstable writes by request size, not folio size", " - nvme-apple: Prevent shared tags across queues on Apple A11", " - nvmet: fix refcount leak in nvmet_sq_create()", " - netdev-genl: report NAPI thread PID in the caller's pid namespace", " - can: esd_usb: kill anchored URBs before freeing netdevs", " - can: isotp: use unconditional synchronize_rcu() in isotp_release()", " - can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER", " - can: isotp: serialize TX state transitions under so->rx_lock", " - 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: Reset register bounds before narrowing retval range in", " check_mem_access()", " - bpf,fork: wipe ->bpf_storage before bailouts that access it", " - bpf: Add missing access_ok call to copy_user_syms", " - block: remove redundant GD_NEED_PART_SCAN in add_disk_final()", " - block: fix race in blk_time_get_ns() returning 0", " - block: fix IORING_URING_CMD_REISSUE flags check in blkdev_uring_cmd", " - 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-pcache: reject option groups without values", " - 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: fix leaking uninitialized kernel memory", " - dm-integrity: fix a bug if the bio is out of limits", " - dm-integrity: don't increment hash_offset twice", " - dm-verity: avoid double increment of &use_bh_wq_enabled", " - dm-verity: fix a possible NULL pointer dereference", " - dm-verity: increase sprintf buffer size", " - dm-verity: make error counter atomic", " - dma-fence: Make dma_fence_dedup_array() robust against 0-count input", " - accel/amdxdna: Fix use-after-free in amdxdna_gem_dmabuf_mmap()", " - accel/ivpu: Reject firmware log with size smaller than header", " - 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: 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 - only expose sysfs attributes on control interface", " - 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 firmware leak in async update", " - 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", " - tracing/user_events: Fix use-after-free in user_event_mm_dup()", " - wifi: libertas_tf: fix use-after-free in lbtf_free_adapter()", " - posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu()", " - selftests/ftrace: Drop invalid top-level local in test_ownership", " - cpu: hotplug: Preserve per instance callback errors", " - cpu: hotplug: Bound hotplug states sysfs output", " - gpio: mt7621: more robust management of IRQ domain teardown", " - gpio: tegra: do not call pinctrl for GPIO direction", " - gpio: mt7621: be sure IRQ domain is created before exposing GPIO chips", " - gpio-f7188x: Add support for NCT6126D version B", " - gpio: mt7621: avoid corruption of shared interrupt trigger state", " - gpios: palmas: add .get_direction() op", " - net: sit: require CAP_NET_ADMIN in the device netns for changelink", " - net: ethernet: ti: icssg: guard PA stat lookups", " - 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", " - selftests: net: fix file owner for broadcast_ether_dst test", " - 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", " - net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for", " changelink", " - octeontx2-af: Free BPID bitmap on setup failure", " - 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", " - platform/x86/amd/pmc: Avoid logging \"(null)\" for DMI values", " - net/sched: sch_teql: move rcu_read_lock()/spin_lock() from _bh variants", " - drm/xe/userptr: Stub notifier_lock helpers when DRM_GPUSVM=n", " - pwm: rzg2l-gpt: Fix period_ticks type from u32 to u64", " - LoongArch: Fix nr passing in set_direct_map_valid_noflush()", " - LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()", " - ipmi: Fix user refcount underflow in event delivery", " - ipmi: fix refcount leak in i_ipmi_request()", " - bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()", " - rtc: renesas-rtca3: Fix PIE clear polling condition in alarm setup error", " path", " - 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", " - fhandle: reject detached mounts in capable_wrt_mount()", " - hwmon: (max1619) add missing 'select REGMAP' to Kconfig", " - tracing/probes: Fix double addition of offset for @+FOFFSET", " - net/mlx5: HWS, fix matcher leak on resize target setup failure", " - 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", " - mm/compaction: handle free_pages_prepare() properly in compaction_free()", " - irqchip/irq-riscv-imsic-early: Fix fwnode leak on state setup failure", " - s390/monwriter: Reject buffer reuse with different data length", " - mac802154: remove interfaces with RCU list deletion", " - octeontx2-pf: fix SQB pointer leak on init failure", " - selftests: net: make busywait timeout clock portable", " - llc: fix SAP refcount leak in llc_ui_autobind()", " - ipvs: use parsed transport offset in SCTP state lookup", " - macsec: don't read an unset MAC header in macsec_encrypt()", " - dibs: loopback: validate offset and size in move_data()", " - net: macb: drop in-flight Tx SKBs on close", " - arm64: smp: Fix hot-unplug tearing by forcing unregistration", " - cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()", " - fs/resctrl: Free mon_data structures on rdt_get_tree() failure", " - fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list", " - ata: libata-core: Skip HPA resize for locked drives", " - ata: libata-core: Allow capacity transition to zero for locked drives", " - riscv: Prevent NULL pointer dereference in machine_kexec_prepare()", " - tracing/osnoise: Call synchronize_rcu() when unregistering", " - s390/diag: Add missing array_index_nospec() call to", " memtop_get_page_count()", " - s390/mm: Fix type mismatch in get_align_mask().", " - selftests/rseq: Fix a building error for riscv arch", " - 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", " - selftests/landlock: Skip scoped_signal subtest with MSG_OOB if not", " available", " - selftests/landlock: Fix screwed up pointers in the scoped_signal_test", " - mmc: sdhci-esdhc-imx: restore pinctrl before restoring ios timing on", " resume", " - powerpc/pseries: fix memory leak on krealloc failure in papr_init", " - net/mlx5: free mlx5_st_idx_data on final dealloc", " - wifi: rt2x00: avoid full teardown before work setup in probe", " - wifi: mwifiex: fix roaming to different channel in host_mlme mode", " - wifi: mac80211: fix memory leak in ieee80211_register_hw()", " - wifi: brcmfmac: cyw: fix heap overflow on a short auth frame", " - riscv: vdso: Do not use LTO for the vDSO", " - 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", " - reset: sunxi: fix memory region leak on ioremap failure", " - powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()", " - wifi: cfg80211: validate EHT MLE before MLD ID read", " - wifi: ieee80211: validate MLE common info length", " - 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", " - mmc: block: fix RPMB device unregister ordering", " - mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe()", " method", " - mmc: sdhci-esdhc-imx: remove unnecessary mmc_card_wake_sdio_irq check", " for tuning save/restore", " - mmc: sdhci-esdhc-imx: restore DLL override for DDR modes on resume", " - mmc: sdhci-esdhc-imx: fix esdhc_change_pinstate() to allow default state", " restore", " - mmc: sdhci-esdhc-imx: disable irq during suspend to fix unhandled", " interrupt", " - mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspend", " - mmc: sdhci-esdhc-imx: make non-fatal errors non-blocking in suspend", " - mmc: sdhci-esdhc-imx: fix resume error handling", " - crypto: xilinx-trng - Remove crypto_rng interface", " - 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: hid-sensor-rotation: Fix stale or zero output when reading raw", " values", " - ALSA: scarlett2: Allow selecting config_set by firmware version", " - ALSA: scarlett2: Update offsets for 2i2 Gen 4 firmware 2417", " - firmware_loader: Add cancel helper for async requests", " - ALSA: hda/tas2781: Cancel async firmware request at unbind", " - binder: Use LIST_HEAD() to initialize on stack list head", " - binder: cache secctx size before release zeroes it", " - staging: rtl8723bs: fix spaces around binary operators", " - Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister", " - Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()", " - proc: rename proc_setattr to proc_nochmod_setattr", " - usb: dwc3: Support USB3340x ULPI PHY high-speed negotiation.", " - usb: dwc3: fix dwc3_readl() and dwc3_writel() calls in dwc3_ulpi_setup()", " - usb: atm: ueagle-atm: use dev_dbg() for 'device found' message", " - usb: atm: ueagle-atm: remove function entry/exit debug messages", " - usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()", " - btrfs: remove folio parameter from ordered io related functions", " - KVM: arm64: Ensure level is always initialized when relaxing perms", " - KVM: arm64: Fix propagation of TLBI level in", " kvm_pgtable_stage2_relax_perms()", " - mm/damon/core: always put unsuccessfully committed target pids", " - mm/damon/core: trace esz at first setup", " - samples/damon/mtier: fail early if address range parameters are invalid", " - perf callchain: Handle multiple address spaces", " - soc: fsl: qe_ports_ic: Add missing cleanup on device removal", " - drm/rockchip: inno-hdmi: Switch to drmm_kzalloc()", " - accel/amdxdna: Create shared functions for AIE2 and AIE4", " - Revert \"UBUNTU: SAUCE: accel/amdxdna: Support sensors for column", " utilization\"", " - accel/amdxdna: Support sensors for column utilization", " - accel/amdxdna: Adjust size for copy_to_user()", " - accel/amdxdna: Handle DETACH_DEBUG_BO through config_debug_bo path", " - accel/amdxdna: Fix order of canceled mailbox messages", " - accel/amdxdna: Guard management mailbox channel cleanup against NULL", " pointer", " - drm/amdkfd: fix redundant MQD iterations in GFX v12.1", " - wifi: ath12k: Fix invalid IRQ requests during AHB probe", " - libbpf: Fix deduplication of typedef with base definitions", " - spi: atcspi200: Use helper function devm_clk_get_enabled()", " - spi: atcspi200: fix use-after-free when driver unbind", " - arm64: dts: rockchip: Fix vdec register blocks order on RK3576", " - arm64: dts: rockchip: Update vdec register blocks order on RK3588", " - dt-bindings: net: bluetooth: qualcomm: Fix WCN6855 regulator names", " - x86/bug: Add printf() validation to HAVE_ARCH_BUG_FORMAT_ARGS WARNs", " - arm64: dts: qcom: milos: Reduce rmtfs_mem size to 2.5MiB", " - arm64: dts: qcom: sdm845-oneplus: Drop address from framebuffer node", " - arm64: dts: qcom: sdm845-shift-axolotl: Correct touchscreen sleep state", " - soc: xilinx: Fix race condition in event registration", " - wifi: ath11k: cancel SSR work items during PCI shutdown", " - ixgbe: fix unaligned u32 access in ixgbe_update_flash_X550()", " - objtool/klp: Fix is_uncorrelated_static_local() for Clang", " - objtool/klp: Fix .data..once static local non-correlation", " - objtool/klp: Fix create_fake_symbols() skipping entsize-based sections", " - objtool/klp: Fix handling of zero-length .altinstr_replacement sections", " - objtool/klp: Fix cloning of zero-length section symbols", " - objtool/klp: Fix extraction of text annotations for alternatives", " - objtool/klp: Fix relocation conversion failures for R_X86_64_NONE", " - objtool/klp: Use sym->demangled_name for symbol_name hash", " - objtool/klp: Match symbols based on demangled_name for global variables", " - objtool: Replace iterator callback with for_each_sym_by_mangled_name()", " - objtool: Fix reloc hash collision in find_reloc_by_dest_range()", " - klp-build: Fix hang on out-of-date .config", " - klp-build: Fix checksum comparison for changed offsets", " - riscv: dts: microchip: gpio controllers on mpfs need 2 interrupt cells", " - riscv: dts: microchip: remove gpio hogs from beaglev-fire", " - wifi: cfg80211: restrict LMR feedback check to TB and non-TB ranging", " - drm/panel: Clean up SOFEF00 config dependencies", " - drm/panel: Clean up S6E3FC2X01 config dependencies", " - arm64: dts: marvell: samsung-coreprimevelte: Increase touchscreen", " voltage", " - arm64: dts: imx8mn-vhip4-evalboard-v1: Correct interrupt flags", " - arm64: dts: imx8mn-vhip4-evalboard-v2: Correct interrupt flags", " - crypto: ccp - Check for page allocation failure correctly in TIO", " - crypto: ccp - Initialize data during __sev_snp_init_locked()", " - accel/amdxdna: Fix clflush buffer size", " - ntb: Store original DMA address for future release", " - ntb: Use consistent DMA attributes when freeing DMA mappings", " - riscv: dts: spacemit: k3: add clock tree", " - dts: riscv: spacemit: correct 32k clock frequency", " - arm64: dts: qcom: sdm660: set cdsp compute-cbs' regs properly", " - arm64: dts: qcom: sdm630: set adsp compute-cbs' regs properly", " - arm64: dts: qcom: lemans: Move PCIe devices into soc node", " - sockptr: fix usize check in copy_struct_from_sockptr() for user pointers", " - arm64: dts: mediatek: mt7988a-bpi-r4pro: rework pcie gpio-hog handling", " - rhashtable: give each instance its own lockdep class", " - thermal: hwmon: Register a hwmon device for each thermal zone", " - crypto: ccp/sev-dev-tsm - bail out early when pdev->bus is NULL", " - crypto: safexcel - Fix potential memory leak in safexcel_pci_probe()", " - net/sched: add qdisc_qlen_inc() and qdisc_qlen_dec()", " - net/sched: sch_dualpi2: annotate data-races in dualpi2_dump_stats()", " - tools/rtla: Fix --dump-tasks usage in timerlat", " - rtla: Stop the record trace on interrupt", " - dm: limit target bio polling to one shot", " - selftests/bpf: Override EXTRA_LDFLAGS for static builds", " - sched/fair: Update util_est after updating util_avg during dequeue", " - hfs: fix incorrect inode ID assignment in hfs_new_inode()", " - vfio: selftests: Fix out-of-tree build with make O=", " - vfio: selftests: Allow builds when ARCH=x86", " - vfio/xe: avoid duplicate reset in xe_vfio_pci_reset_done", " - arm64: dts: qcom: kaanapali: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sdm845-xiaomi-beryllium: Correct IPA FW path", " - ASoC: mediatek: mt8189: Fix probe resource cleanup", " - drm/msm/mdss: correct UBWC programming sequences", " - tools/nolibc: stackprotector: Avoid stalling program startup if crng is", " not init yet", " - ASoC: dapm: Fix widget lookup with prefixed names across DAPM contexts", " - ACPI: PAD: Fix teardown ordering in acpi_pad_remove()", " - wifi: ath12k: fix error unwind on arch_init() failure in PCI probe", " - cpufreq: governor: Fix data races on per-CPU idle/nice baselines", " - cpufreq: governor: Fix stale prev_cpu_nice spike when enabling", " ignore_nice_load", " - dt-bindings: vendor-prefixes: Add Verbatim Corporation", " - drm/tegra: fbdev: Do not assign to struct drm_fb_helper.info", " - rust: devres: add 'static bound to Devres", " - lib/base64: validate before writing in decode tail path", " - rust: uaccess: use INLINE_COPY_TO_USER to guard copy_to_user()", " - uaccess: unify inline vs outline copy_{from,to}_user() selection", " - uaccess: minimize INLINE_COPY_USER-related ifdefery", " - crypto: ccp/tsm - Enable the root port after the endpoint", " - firmware: samsung: acpm: Add devm_acpm_get_by_phandle helper", " - firmware: samsung: acpm: remove compile-testing stubs", " - drm/msm/a8xx: Make a8xx_recover IFPC safe", " - drm/msm/a8xx: Fix RSCC offset", " - EDAC/igen6: Fix memory topology parsing for Panther Lake-H SoCs", " - arm: dts: bcm2711: Fix typo in gpio-line-names", " - arm64: dts: renesas: r8a78000: Fix GIC-720AE View 1 Redistributor", " description", " - arm64: dts: renesas: ironhide: Describe all reserved memory", " - md: replace wait loop with wait_event() in md_handle_request()", " - md/raid1,raid10: fix deadlock in read error recovery path", " - md/raid1,raid10: fix error-path detection with md_cloned_bio()", " - md/raid1,raid10: fix bio accounting for split md cloned bios", " - liveupdate: Use refcount_t for FLB reference counts", " - liveupdate: Reference count incoming FLB data", " - liveupdate: skip serialization for context-preserving kexec", " - liveupdate: fix TOCTOU race in luo_session_retrieve()", " - liveupdate: block session mutations during reboot", " - spi: imx: replace dmaengine_terminate_all() with", " dmaengine_terminate_sync()", " - wifi: ath12k: fix memory leak in ath12k_wifi7_dp_rx_h_verify_tkip_mic()", " - wifi: ath12k: fix inconsistent arvif state in vdev_create error paths", " - ACPI: button: Fix lid_device value leak past driver removal", " - drm/amd/pm: Add empty string validation to sysfs store functions", " - accel/amdxdna: Return errors for failed debug BO commands", " - mm: preserve PG_dropbehind flag during folio split", " - perf/x86/intel/uncore: Fix PCI device refcount leak in UPI discovery", " - wifi: wlcore: enable the right set of ciphers", " - cxl/test: Fix __fortify_panic", " - bpf: Take mmap_lock in zap_pages()", " - ocfs2: fix out-of-bounds write in ocfs2_remove_refcount_extent", " - cxl/pci: Fix the incorrect check of pci_read_config_word() return", " - cxl/pci: Convert PCIBIOS errors to errno on DVSEC config accesses", " - netfilter: cttimeout: detach dataplane timeout policy and repurpose", " refcount", " - arm64: dts: imx94: fix DDR PMU interrupt number", " - arm64: dts: freescale: fsl-ls1028a-tqmls1028a-mbls1028a: switch mmc", " aliases", " - selftests/bpf: Fix flaky file_reader test", " - riscv: alternative: Use IS_ENABLED() over ifdeffery for", " apply_vdso_alternatives()", " - riscv: alternative: Pass vDSO start as parameter to", " apply_vdso_alternatives()", " - riscv: alternative: Also patch the CFI vDSO", " - bpf: Verifier support for sleepable tracepoint programs", " - bpf: Reject sleepable BPF_LSM_CGROUP programs at load time", " - netfilter: flowtable: avoid num_encaps underflow on bridge VLAN untag", " - filelock: fix break_lease() stub signature for CONFIG_FILE_LOCKING=n", " - wifi: mac80211: bound S1G TIM PVB walk to the TIM element", " - ACPI: processor: Add cpuidle driver check in", " acpi_processor_register_idle_driver()", " - RDMA/nldev: Fix locking when accessing mr->pd", " - scsi: ufs: core: Handle PM commands timeout before SCSI EH", " - iommufd: Destroy the pages content after detaching from dmabuf", " - lib/test_hmm: fix memory leak in dmirror_migrate_to_system()", " - rust: kbuild: show the right `quiet_cmd_rustc_procmacrolibrary`", " - remoteproc: qcom_q6v5_wcss: drop redundant wcss_q6_bcr_reset", " - wifi: mt76: mt7996: remove redundant pdev->bus check in probe", " - wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bits", " - memory: tegra186-emc: stop borrowing MC aggregate hook for EMC", " - PM: QoS: Fix misc device registration unwind", " - btrfs: lzo: reject compressed segment that overflows the compressed", " input", " - ixgbe: do not configure xps for XDP queues", " - bpf: Cancel special fields on map value recycle", " - clocksource: move NXP timer selection to drivers/clocksource", " - [Config] Allow certain NXP timer selections for arm64", " - vduse: fix compat handling for VDUSE_IOTLB_GET_FD/VDUSE_VQ_GET_INFO", " - iomap: pass the correct len to fserror_report_io in __iomap_write_begin", " - ASoC: cs35l56: Prevent double-free of debugfs", " - ASoC: cs35l56: Cleanup if component_probe fails", " - hwmon: (gpd-fan): drop global driver data and use per-device allocation", " - hwmon: (gpd-fan): Initialize EC before registering hwmon device", " - hwmon: (gpd-fan): fix race condition between device removal and sysfs", " access", " - ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT", " - cxl/test: Verify cmd->size_in before accessing payload", " - m68k: mcf5441x: fix clocks numbering", " - pinctrl: airoha: an7583: add missed gpio32 pin group", " - pinctrl: airoha: an7583: fix misprint in gpio19 pinconf", " - pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin", " function", " - pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin", " function", " - pinctrl: airoha: fix pwm pin function for an7581 and an7583", " - pinctrl: airoha: an7583: fix gpio21 pin group", " - pinctrl: airoha: an7583: add missed gpio22 pin group", " - pinctrl: airoha: an7583: fix phy1_led1 pin function", " - pinctrl: airoha: an7583: remove undefined groups from pcm_spi pin", " function", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_setup() for non-", " serdev device", " - Bluetooth: btintel: Replace CNVi id with hardware variant", " - Bluetooth: btintel: Add DSBR support for ScP2 onwards", " - Bluetooth: btintel_pcie: Load IOSF debug regs by controller variant", " - ASoC: cs35l56: Fix wrong error test on simple_write_to_buffer()", " - ASoC: SOF: Intel: select SND_SOC_SDW_UTILS=y from", " SND_SOC_SOF_HDA_GENERIC=y", " - ASoC: meson: aiu: Validate written enum values", " - ASoC: topology: Check PCM and DAI name strings before use", " - ipv4: fib: Don't dump dying fib_info in fib_leaf_notify().", " - iommu/dma-iommu: Fix wrong scatterlist length assignment in P2PDMA path", " - iommufd: Clarify IOAS_MAP_FILE dma-buf support", " - cxl/region: Fill first free targets[] slot during auto-discovery", " - vfio: selftests: Ensure libvfio output dirs are always created", " - cxl/region: Block region delete during region creation", " - cxl/region: Resolve region deletion races", " - cxl/memdev: Pin parents for entire memdev lifetime", " - net: airoha: Fix error handling in airoha_ppe_flush_sram_entries()", " - netfilter: nft_fwd_netdev: use recursion counter in neigh egress path", " - netfilter: nf_dup_netdev: add nf_dev_xmit_recursion*() helpers and use", " them", " - geneve: Fix off-by-one comparing with GRO_LEGACY_MAX_SIZE", " - smb: client: fix conflicting option validation for new mount API", " - btrfs: Drop WQ_PERCPU from ordered_flags in btrfs_init_workqueues()", " - bpf: Guard __get_user acesss with access_ok for uprobe_multi data", " - net: ti: icssg-prueth: Fix AF_XDP fill ring alloc and wakeup condition", " - net: ti: icssg: Use undirected TX tag for native XDP in HSR offload mode", " - net: ti: icssg: Use undirected TX tag for XDP zero copy in HSR offload", " mode", " - RDMA/bnxt_re: Free CQ toggle page after firmware teardown", " - RDMA/bnxt_re: Reject GET_TOGGLE_MEM when toggle page was not allocated", " - RDMA/hns: Fix memory leak of bonding resources", " - mfd: bd72720: Drop BUCK11 ID", " - 9p: Add missing read barrier in virtio zero-copy path", " - perf dwarf-aux: Fix libdw segmentation fault in cu_walk_functions_at", " - perf dwarf-aux: Fix libdw API contract violations", " - perf srcline: Introduce inline_node__clear_frames()", " - perf libdw: Fix libdw API contract violations and memory leaks", " - perf probe-finder: Fix libdw API contract violations", " - perf annotate-data: Fix libdw API contract violations", " - coresight: tmc: Fix overflow when calculating is bigger than 2GiB", " - perf tool: Fix missing schedstat delegates and dont_split_sample_group", " in delegate_tool", " - PCI: intel-gw: Move interrupt enable to own function", " - PCI: intel-gw: Enable clock before PHY init", " - PCI: intel-gw: Add .start_link() callback", " - bus: mhi: ep: Add missing state_lock protection for mhi_state access", " - PCI: dwc: Apply ECRC workaround for DesignWare cores prior to 5.10a", " - PCI: qcom: Set max OPP before DBI access during resume", " - perf pmu-events AMD: Switch l2_itlb_misses to", " bp_l1_tlb_miss_l2_tlb_miss.all", " - perf unwind: Refactor get_entries to allow dynamic libdw/libunwind", " selection", " - coresight: Handle helper enable failure properly", " - mailbox: don't free the channel if the startup callback failed", " - PCI/pwrctrl: Lock device when calling device_is_bound()", " - coresight: platform: defer connection counter increment until alloc", " succeeds", " - platform/x86: classmate-laptop: Address memory leaks on driver removal", " - clk: microchip: mpfs-ccc: fix peripheral driver registration failures", " after oob fix", " - perf sample: Add evsel to struct perf_sample", " - perf event: Fix size of synthesized sample with branch stacks", " - perf inject: Fix itrace branch stack synthesis", " - gpib: cb7210: Fix region leak when request_irq fails", " - timers/migration: Update stale @online doc to @available", " - clk: spacemit: k3: Switch to pll2_d6 as parent for PCIe clock", " - clk: spacemit: k3: Fix PCIe clock register offset", " - fs/ntfs3: fix wrong LCN in run_remove_range() when splitting a run", " - ntfs3: Allocate iomap inline_data using alloc_page", " - perf sample: Add file_offset field to struct perf_sample", " - perf sched: Replace BUG_ON on invalid CPU with graceful skip", " - perf sched: Fix NULL dereference in latency_runtime_event", " - perf sched: Fix comp_cpus heap overflow with cross-machine recordings", " - perf tools: Guard remaining test_bit calls from OOB sample CPU", " - perf sched: Fix thread reference leaks in timehist_get_thread()", " - perf sched: Use is_idle_sample() for idle thread runtime cast guard", " - perf sched: Fix thread reference leak in idle hist processing", " - perf sched: Free callchain nodes in idle thread cleanup", " - docs: memfd_preservation: fix rendering of ABI documentation", " - virtio: add missing kernel-doc for map and vmap members", " - fs/ntfs3: prevent potential lcn remains uninitialized", " - perf tools: NULL bitmap pointers after bitmap_free()", " - perf tools: Use scnprintf() in build_id__snprintf() and hwmon", " read_events()", " - perf data convert json: Fix addr_location leak on time-filtered samples", " - perf tools: Use mkostemp() for O_CLOEXEC on temporary files", " - phy: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put", " in reset", " - sparc: Avoid -Wunused-but-set-parameter in clear_user_page()", " - apparmor: release exe file resources on path failure", " - apparmor: remove unnecessary goto and associated label", " - apparmor: Fix inverted comparison in cache_hold_inc()", " - i3c: mipi-i3c-hci: Fix suspend behavior when bus disable falls back to", " software reset", " - i3c: master: Serialize i3c_set_hotjoin() with the maintenance lock", " - i3c: mipi-i3c-hci: Fix race in i3c_hci_addr_to_dev()", " - perf maps: Add maps__mutate_mapping", " - perf c2c: Free format list entries when releasing c2c hist entries", " - regcache: Do not overwrite error code when finalizing cache after error", " - erofs: call erofs_exit_ishare() before rcu_barrier()", " - perf c2c: Free format list entries when c2c_hists__init() fails", " - perf c2c: Fix hist entry and format list leaks in c2c_he_free()", " - drm/amd/display: Skip PHY SSC reduction on some 8K panels", " - net: ethernet: mtk_eth_soc: fix supported_interface set after", " phylink_create", " - selftests/ftrace: Fix trace_marker_raw test on 64K page kernels", " - octeontx2-af: npc: Log successful MCAM drop-on-non-hit install at debug", " level", " - netconsole: don't drop the last byte of a full-sized message", " - eth: fbnic: take netif_addr_lock_bh() around rx mode address programming", " - arm64: static_call: include asm/insns.h", " - md/raid1: fix writes_pending and barrier reference leaks on write", " failures", " - md/raid10: fix writes_pending leak on write request failures", " - md/raid10: fix writes_pending and barrier reference leaks on discard", " failures", " - netfilter: ipset: Don't use test_bit() in lockless RCU readers in bitmap", " types", " - selftests/mm: fix hugetlb pathname construction in", " charge_reserved_hugetlb.sh", " - selftests/mm: run_vmtests.sh: free memory if available memory is low", " - selftests/mm: move hwpoison setup into run_test() and silence modprobe", " output for memory-failure category", " - selftests/mm: remove hardcoded THP sizing assumptions in hmm tests", " - net: dst_metadata: fix false-positive memcpy overflow in tun_dst_unclone", " - bpf: Fix partial copy of non-linear test_run output", " - bpf: Fix BPF_PROG_ASSOC_STRUCT_OPS last field check", " - erofs: handle 48-bit blocks_hi for compressed inodes", " - ASoC: cs530x: Fix expected MCLK rates for CS5302/4/8", " - PCI: endpoint: pci-epf-vntb: Document legacy MSI doorbell offset", " - PCI: endpoint: pci-epf-vntb: Defer pci_epc_raise_irq() out of atomic", " context", " - PCI: endpoint: pci-epf-vntb: Report 0-based doorbell vector via", " ntb_db_event()", " - e1000e: Reconfigure PLL clock gate timeout and re-enable K1 on Meteor", " Lake", " - bpf: Guard conntrack opts error writes", " - selftests/bpf: Cover small conntrack opts error writes", " - netfilter: nf_conntrack_helper: dynamically allocate struct", " nf_conntrack_helper", " - netfilter: nf_conntrack_pptp: move GRE specific cleanup to GRE tracker", " - netfilter: nf_conntrack_gre: fix gre keymap list corruption", " - netfilter: conntrack: check NULL when retrieving ct extension", " - netfilter: nf_conntrack_expect: use conntrack GC to reap expectations", " - netfilter: nf_conntrack_expect: store master_tuple in expectation", " - netfilter: nf_conntrack_expect: run expectation eviction with no helper", " - netfilter: nft_ct: expectation timeouts are passed in milliseconds", " - netfilter: nf_conntrack_helper: cap maximum number of expectation at", " helper registration", " - cpuidle: Allow exit latency to exceed target residency", " - ASoC: SDCA: Validate written enum value in ge_put_enum_double()", " - ASoC: rt5575: Use __le32 for SPI burst write address", " - PCI: endpoint: pci-epf-vntb: Exclude reserved slots from db_valid_mask", " - net: ti: icssg: Fix XSK zero copy TX during application wakeup", " - net: lwtunnel: Drop skb metadata before LWT encapsulation", " - sctp: fix err_chunk memory leaks in INIT handling", " - net: dsa: mxl862xx: avoid unaligned 16-bit access in api_wrap", " - octeontx2-af: fix CGX debugfs RVU AF PCI reference leaks", " - geneve: gate GRO hint in geneve_gro_complete() on gs->gro_hint", " - geneve: validate inner network offset in geneve_gro_complete()", " - tools: ynl: build archives with $(AR)", " - net: enetc: fix potential divide-by-zero when num_vsi is zero", " - udp_tunnel: Pass struct sock to setup_udp_tunnel_sock().", " - tipc: avoid busy looping in tipc_exit_net()", " - bpf: Mask pseudo pointer values in verifier logs", " - bpf: Fix insn_aux_data leak on verifier err_free_env path", " - hwmon: (pmbus/core) Add support for NVIDIA nvidia195mv mode", " - hwmon: (pmbus/core) honor vrm_version in pmbus_data2reg_vid()", " - gpio: shared-proxy: always serialize with a sleeping mutex", " - drm/panthor: Always use the IRQ-safe variant when acquiring the fence", " lock", " - drm/panthor: Keep the reset work disabled until everything is", " initialized", " - drm/panthor: Fix panthor_pwr_unplug()", " - spi: rzv2h-rspi: Fix DMA transfer error handling for signal interruption", " - xen/pvcalls: bound backend response req_id before indexing rsp[]", " - afs: Remove setting of AS_RELEASE_ALWAYS for symlinks and mountpoints", " - afs: Fix directory inode initialisation order", " - afs: Use scoped_seqlock_read() rather than manually doing seqlock stuff", " - afs: Fix leak of ungot volume", " - iomap: release pages on atomic dio size mismatch", " - cachefiles: Fix double unlock in nomem_d_alloc error path", " - cachefiles: Fix file burial to take lock when unsetting S_KERNEL_FILE", " - drm/imagination: Fix returned size for DRM_IOCTL_PVR_DEV_QUERY", " - iio: dac: mcp47feb02: Fix passing uninitialized vref1_uV for no Vref1", " case", " - net/mlx5: LAG, replace pf array with xarray", " - net/mlx5: LAG, use xa_alloc to manage LAG device indices", " - net/mlx5: Lag: refactor representor reload handling", " - net/mlx5: E-Switch, add representor lifecycle lock", " - net/mlx5: Lag, avoid LAG and representor lock cycles", " - net/mlx5: LAG, factor out shared FDB code into dedicated file", " - net/mlx5: LAG, replace peer count check with direct peer lookup", " - net/mlx5: LAG, prepare for SD device integration", " - net/mlx5: LAG, replace mlx5_get_dev_index with LAG sequence number", " - net/mlx5: LAG, extend shared FDB API with group_id filter", " - net/mlx5: LAG, Fix off-by-one in single-FDB error rollback", " - ksmbd: fix multichannel binding and enforce channel limit", " - smb: client: preserve leading slash for POSIX absolute symlink targets", " - gpio: shared: make the voting mechanism adaptable", " - drm/i915/ltphy: Fix SSC Enablement bit in PORT_CLOCK_CTL", " - Bluetooth: 6lowpan: avoid untracked enable work", " - Bluetooth: btintel_pcie: Support Product level reset", " - [Config] Make BT_INTEL_PCIE depend on ACPI", " - Bluetooth: btintel_pcie: Add support for smart trigger dump", " - Bluetooth: btintel_pcie: Separate coredump work from RX work", " - Bluetooth: btintel_pcie: Refactor FLR to use device_reprobe()", " - Bluetooth: ISO: fix malformed ISO_END/CONT handling", " - accel/amdxdna: Prevent PM resume deadlock in hwctx_sync_debug_bo()", " - accel/amdxdna: Fix VMA access race", " - net: rnpgbe: fix mailbox endianness and remove pointer casts", " - drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE", " - smb: client: fix busy dentry warning on unmount after DIO", " - drm/fb-helper: Only consider active CRTCs for vblank sync", " - ethtool: rss: Fix hfunc and input_xfrm parsing on big endian", " - drm/imagination: make pvr_fw_trace_init_mask_ops static", " - VDUSE: avoid leaking information to userspace", " - ASoC: SOF: ipc4-control: Validate notification payload size", " - arm64: dts: renesas: ironhide: Describe inline ECC carveouts", " - arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers", " - KVM: s390: vsie: Fix allocation of struct vsie_rmap", " - KVM: s390: vsie: Add missing radix_tree_preload() in", " _gaccess_shadow_fault()", " - KVM: s390: Add some useful mask macros", " - KVM: s390: vsie: Fix rmap handling in _do_shadow_crste()", " - KVM: s390: vsie: Fix redundant rmap entries", " - KVM: s390: vsie: Use mmu cache to allocate rmap", " - KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory", " - KVM: TDX: Reject concurrent change to CPUID entry count", " - ASoC: SOF: topology: fix memory leak in snd_sof_load_topology", " - netfilter: nft_fib: reject fib expression on the netdev egress hook", " - netfilter: nf_conntrack_sip: remove net variable shadowing", " - netfilter: nf_conntrack_sip: validate skb_dst() before accessing it", " - gpu/buddy: bail out of try_harder when alignment cannot be honoured", " - backlight: ktd2801: Enable BL_CORE_SUSPENDRESUME", " - cxl: Fix CXL_HEADERLOG_SIZE to match RAS Capability size", " - pinctrl: renesas: rzg2l: Use -ENOTSUPP instead of -EOPNOTSUPP", " - remoteproc: xlnx: Check remote core state", " - mm/sparse-vmemmap: fix vmemmap accounting underflow", " - mm/huge_memory: preserve pmd_swp_uffd_wp on device-private PMD downgrade", " - fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race", " - fs/proc/task_mmu: do not warn on seeing non-migration pmd entry", " - kho: make sure scratch size is always aligned by CMA_MIN_ALIGNMENT_BYTES", " - mtd: maps: vmu-flash: fix fault in unaligned fixup", " - dmaengine: dw-edma-pcie: Reject devices without driver data", " - dmaengine: sh: rz-dmac: Move interrupt request after everything is set", " up", " - platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8D26)", " - platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8E35)", " - spi: imx: reconfigure for PIO when DMA cannot be started", " - ovl: use linked upper dentry in copy-up tmpfile", " - can: bcm: add locking when updating filter and timer values", " - can: bcm: extend bcm_tx_lock usage for data and timer updates", " - can: bcm: fix CAN frame rx/tx statistics", " - can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()", " - can: bcm: fix stale rx/tx ops after device removal", " - can: bcm: track a single source interface for ANYDEV timeout/throttle", " ops", " - can: bcm: validate frame length in bcm_rx_setup() for RTR replies", " - can: bcm: add missing device refcount for CAN filter removal", " - selftests/bpf: Cover negative buffer pointer offsets", " - dm: avoid leaking the caller's thread keyring via the table device file", " - dma-buf: protected fence ops by RCU v8", " - dma-fence: use correct callback in dma_fence_timeline_name()", " - accel/amdxdna: reject command submission on devices without a submit op", " - accel/amdxdna: reject user command submission without a command BO", " - accel/amdxdna: Use caller client for debug BO sync", " - fs/resctrl: Fix use-after-free during unmount", " - mmc: vub300: fix use-after-free on probe failure", " - octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF", " - ksmbd: fix stack buffer overflow in multichannel session-key copy", " - netfilter: nfnetlink_cthelper: cap to maximum number of expectation per", " master", " - netfilter: nfnetlink_cthelper: cap to maximum number of expectation per", " master on updates", " - riscv: vdso: Always declare vdso_start symbols", " - ata: libata-core: Add NOLPM quirk for PNY CS900 1TB SSD", " - ata: libata-core: Reject an invalid concurrent positioning ranges count", " - net: ipa: fix SMEM state handle leaks in SMP2P init", " - amdkfd: properly free secondary context id", " - pmdomain: imx93-blk-ctrl: Extract PHY as shared domain for DSI/CSI", " - pmdomain: mediatek: Fix possible nullptr KP in HWV cleanup/on-check", " - arch/riscv: vdso: remove CFI landing pad from rt_sigreturn", " - reset: imx7: Correct polarity of MIPI CSI resets on i.MX8MQ", " - powerpc/uaccess: correct check for CONFIG_PPC_E500 in", " mask_user_address()", " - wifi: mac80211: validate extension-frame layout before RX", " - xfs: factor out a xfs_zone_mark_free helper", " - xfs: add newly added RTGs to the free pool in growfs", " - liveupdate: validate session type before performing operation", " - posix-timers: Expand timer_[re]arm() callbacks with a boolean return", " value", " - posix-cpu-timers: Prevent UAF caused by non-leader exec() race", " - Revert \"gpib: cb7210: Fix region leak when request_irq fails\"", " - Upstream stable to v6.18.40, v7.1.5", " * Resolute update: upstream stable patchset 2026-08-20 (LP: #2164666) //", " CVE-2023-20585", " - 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", " * [Regression] Laptop fails to power off completely when HDMI is connected", " in kernel 7.0.0-28 (LP: #2163121) // CVE-2026-68364", " - drm/amd/display: fix NULL ptr deref in ISM delayed work", " - drm/amd/display: Fix ISM teardown crash from NULL dc dereference", " - drm/amd/display: Fix ISM dc_lock deadlock during suspend", " * CVE-2026-72064", " - net: mana: Sync page pool RX frags for CPU", " * CVE-2026-72065", " - net: mana: Validate the packet length reported by the NIC", " * CVE-2026-72098", " - dm-verity-fec: replace {MAX,MIN}_RSN with {MIN,MAX}_ROOTS", " - dm-verity: fix buffer overflow in FEC calculation", " * CVE-2026-72248", " - netfilter: flowtable: support IPIP tunnel with direct xmit", " - netfilter: flowtable: use correct direction to set up tunnel route", " * CVE-2026-72249", " - netfilter: flowtable: use dst in this direction when pushing IPIP header", " * CVE-2026-72287", " - KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\"", " checks", " * CVE-2026-72329", " - net/liquidio: drop cached VF pci_dev LUT", " * CVE-2026-72355", " - netfs: Fix barriering when walking subrequest list", " * CVE-2026-72412", " - s390/mm: Fix handling of _PAGE_UNUSED pte bit", " * CVE-2026-72417", " - netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto()", " * CVE-2026-72442", " - netfilter: flowtable: fix and simplify IP6IP6 tunnel handling", " * CVE-2026-72463", " - xfrm: Fix dev use-after-free in xfrm async resumption", " * CVE-2026-72477", " - fs/ntfs3: call _ntfs_bad_inode() when failing to rename", " * CVE-2026-72493", " - net: serialize netif_running() check in enqueue_to_backlog()", " * CVE-2026-72494", " - RDMA/irdma: Replace waitqueue and flag with completion", " * CVE-2026-72496", " - RDMA/bnxt_re: Proper rollback if the ioremap fails", " * CVE-2026-74269", " - bnxt: fix head underflow on XDP head-grow", " * CVE-2026-74350", " - ocfs2: validate fast symlink target during inode read", " * CVE-2026-72495", " - RDMA/bnxt_re: Avoid repeated requests to allocate WC pages", " * CVE-2026-72501", " - RDMA/bnxt_re: Initialize dpi variable to zero", " * CVE-2026-72278", " - KVM: arm64: nv: Re-translate VNCR before injecting abort", " * CVE-2026-68083", " - ksmbd: fix path resolution in ksmbd_vfs_kern_path_create", " * CVE-2026-68457", " - ksmbd: use opener credentials for FSCTL mutations", " * CVE-2026-68476", " - ipvs: reload ip header after head reallocation", " * CVE-2026-68477", " - ipvs: fix more places with wrong ipv6 transport offsets", " * CVE-2026-72014", " - drbd: reject data replies with an out-of-range payload size", " * CVE-2026-72020", " - ipvs: reset full ip_vs_seq structs in ip_vs_conn_new", " * CVE-2026-72033", " - orangefs: keep the readdir entry size 64-bit in fill_from_part()", " * CVE-2026-72041", " - espintcp: use sk_msg_free_partial to fix partial send", " * CVE-2026-72046", " - gve: fix header buffer corruption with header-split and HW-GRO", " * CVE-2026-72069", " - locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()", " * CVE-2026-72083", " - scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE", " * CVE-2026-72084", " - scsi: target: Bound PR-OUT TransportID parsing to the received buffer", " * CVE-2026-72085", " - scsi: xen: scsiback: Free unsubmitted command instead of double-putting", " it", " * CVE-2026-72129", " - nvmet-rdma: handle inline data with a nonzero offset", " * CVE-2026-72130", " - nvmet-auth: reject short AUTH_RECEIVE buffers", " * CVE-2026-64551", " - sctp: validate STALE_COOKIE cause length before reading staleness", " * CVE-2026-72137", " - xfrm: nat_keepalive: avoid double free on send error", " * CVE-2026-72139", " - tcp: defer md5sig_info kfree past RCU grace period in tcp_connect", " * CVE-2026-72191", " - ntfs3: validate split-point offset in indx_insert_into_buffer", " * CVE-2026-72192", " - ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head", " * CVE-2026-72194", " - fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow", " * CVE-2026-72217", " - SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing", " * CVE-2026-72220", " - sunrpc: harden rq_procinfo lifecycle to prevent double-free", " * CVE-2026-72221", " - sunrpc: wait for in-flight TLS handshake callback when cancel loses race", " * CVE-2026-72222", " - sunrpc: pin svc_xprt across the asynchronous TLS handshake callback", " * CVE-2026-72226", " - batman-adv: tt: prevent TVLV OOB check overflow", " * CVE-2026-72234", " - batman-adv: access unicast_ttvn skb->data only after skb realloc", " * CVE-2026-72251", " - netfilter: nf_nat_sip: reload possible stale data pointer", " * CVE-2026-72277", " - KVM: arm64: nv: Inject SEA if kvm_translate_vncr() can't resolve PFN", " - KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory", " * CVE-2026-72279", " - KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR", " * CVE-2026-72288", " - KVM: arm64: vgic: Handle race between interrupt affinity change and LPI", " disabling", " * CVE-2026-72289", " - KVM: arm64: vgic: Check the interrupt is still ours before migrating it", " * CVE-2026-72296", " - net: ife: require ETH_HLEN to be pullable in ife_decode()", " * CVE-2026-72299", " - tipc: restrict socket queue dumps in enqueue tracepoints", " * CVE-2026-72317", " - SUNRPC: pin upper rpc_clnt across the TLS connect_worker", " * CVE-2026-72318", " - cifs: validate DFS referral string offsets", " * CVE-2026-72319", " - ipvs: fix PMTU for GUE/GRE tunnel ICMP errors", " - ipvs: ensure inner headers in ICMP errors are in headroom", " * CVE-2026-72320", " - netfilter: nft_lookup: fix catchall element handling with inverted", " lookups", " * CVE-2026-72322", " - ipv6: mcast: Fix potential UAF in MLD delayed work", " * CVE-2026-72323", " - ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()", " * CVE-2026-64541", " - net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket", " * CVE-2026-72339", " - qede: fix off-by-one in BD ring consumption on build_skb failure", " * CVE-2026-72348", " - netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop", " * CVE-2026-72351", " - gue: validate REMCSUM private option length", " * CVE-2026-72366", " - netfs: Fix netfs_create_write_req() to handle async cache object", " creation", " * CVE-2026-72381", " - ksmbd: fix use-after-free of fp->owner.name in durable handle owner", " check", " * CVE-2026-72393", " - eth: fbnic: don't cache shinfo across skb realloc", " * CVE-2026-72398", " - sctp: add INIT verification after cookie unpacking", " * CVE-2026-72399", " - net: enetc: check the number of BDs needed for xdp_frame", " * CVE-2026-64530", " - net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle", " * CVE-2026-72422", " - ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2", " NEGOTIATE", " * CVE-2026-72429", " - ipv6: ioam: fix type confusion of dst_entry", " * CVE-2026-72436", " - 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", " * CVE-2026-72451", " - xfrm: Fix xfrm state cache insertion race", " * CVE-2026-72466", " - xprtrdma: Fix bcall rep leak and unbounded peek", " * CVE-2026-72472", " - nfs: use nfsi->rwsem to protect traversal of the file lock list", " * CVE-2026-72473", " - 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", " * CVE-2026-72491", " - net/9p: fix race condition on rdma->state in trans_rdma.c", " * CVE-2026-72495 // CVE-2026-72501", " - RDMA/bnxt_re: Move the UAPI methods to a dedicated file", " * CVE-2026-74255", " - tipc: fix UAF in tipc_l2_send_msg()", " * CVE-2026-74267", " - net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek", " before restoring qlen", " * CVE-2026-74268", " - tcp: clear sock_ops cb flags before force-closing a child socket", " * CVE-2026-74287", " - sctp: validate embedded address parameter length", " * CVE-2026-74310", " - vhost/net: complete zerocopy ubufs only once", " * CVE-2026-74345", " - RDMA/siw: Fix endpoint/socket association handling", " * CVE-2026-74361", " - nvme: fix FDP fdpcidx bounds check", " * CVE-2026-74376", " - md/raid10: reset read_slot when reusing r10bio for discard", " * CVE-2026-74384", " - nvme-multipath: fix flex array size in struct nvme_ns_head", " * CVE-2026-74394", " - RDMA/srpt: fix integer overflow in immediate data length check", " * CVE-2026-74398", " - ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD", " * CVE-2026-74401", " - dlm: fix add msg handle in send_queue ordered", " * CVE-2026-74406", " - vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().", " * CVE-2026-74427", " - afs: Fix netns teardown to cancel the preallocation charger", " - afs: Fix further netns teardown to cancel the preallocation charger", " * CVE-2026-74428", " - rxrpc: Fix double unlock in rxrpc_recvmsg()", " * CVE-2026-74433", " - rxrpc: Fix UAF in rxgk_issue_challenge()", " * CVE-2026-74434", " - rxrpc: Don't move a peeked OOB message onto the pending queue", " * CVE-2026-74436", " - rxrpc: serialize kernel accept preallocation with socket teardown", " * CVE-2026-64535", " - nvmet-tcp: Fix potential UAF when ddgst mismatch", " * CVE-2026-74439", " - iommu/vt-d: Clear Present bit before tearing down scalable-mode context", " entry", " * CVE-2026-64534", " - nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error", " path", "" ], "package": "linux-riscv-7.0", "version": "7.0.0-38.38.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2165483, 2165484, 2165407, 2166547, 2166443, 2166356, 2165872, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165407, 2165040, 2161748, 2163508, 2163214, 2162904, 2162045, 2164967, 2160082, 2164504, 2156316, 2164716, 2164516, 2163375, 2162803, 2163062, 2132119, 2163293, 2160200, 2158858, 2162704, 2162695, 2164666, 2164666, 2163121 ], "author": "Sarah Emery ", "date": "Sun, 27 Sep 2026 00:11:21 +0200" } ], "notes": "linux-riscv-7.0-headers-7.0.0-38 version '7.0.0-38.38.1~24.04.1' (source package linux-riscv-7.0 version '7.0.0-38.38.1~24.04.1') was added. linux-riscv-7.0-headers-7.0.0-38 version '7.0.0-38.38.1~24.04.1' has the same source package name, linux-riscv-7.0, as removed package linux-headers-7.0.0-34-generic. As such we can use the source package version of the removed package, '7.0.0-34.34.1~24.04.1', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-riscv-7.0-tools-7.0.0-38", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": null }, "to_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-38.38.1~24.04.1", "version": "7.0.0-38.38.1~24.04.1" }, "cves": [ { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-68105", "url": "https://ubuntu.com/security/CVE-2026-68105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix kernel panic during driver load failure Avoid kernel panic if MES init fails during driver load. The KIQ ring is falsely marked as ready as ASICs that use MES, KIQ is owned by MES. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] Call Trace: gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280 __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53 (cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68109", "url": "https://ubuntu.com/security/CVE-2026-68109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68114", "url": "https://ubuntu.com/security/CVE-2026-68114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit e4d99e04b2e9b13b97d3b17804c735f62689db23)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68431", "url": "https://ubuntu.com/security/CVE-2026-68431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate minimum PDU size for transform requests The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68138", "url": "https://ubuntu.com/security/CVE-2026-68138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: serialize qdisc_rtab_list against concurrent get/put qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68082", "url": "https://ubuntu.com/security/CVE-2026-68082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix two unsafe bare decodes in decode_lockers() decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-08 10:16:00 UTC" }, { "cve": "CVE-2026-68159", "url": "https://ubuntu.com/security/CVE-2026-68159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68163", "url": "https://ubuntu.com/security/CVE-2026-68163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_vma_mapped: fix device-private PMD handling Commit 65edfda6f3f2 (\"mm/rmap: extend rmap and migration support device-private entries\") introduced the concept of device-private PMD entries, but did not correctly update the rmap walk code to account for them. As a result, when page_vma_mapped_walk() encounters device-private PMD entries, it takes no action other than to acquire the PMD lock and exit. However this is highly problematic for two reasons - firstly, device private entries possess a PFN so check_pmd() needs to be called to ensure an overlapping PFN range. Secondly, and more importantly, if PVMW_MIGRATION is set the caller assumes the returned entry is a migration entry, resulting in memory corruption when the caller tries to interpret the device private entry as such. In addition, commit 146287290023 (\"mm/huge_memory: implement device-private THP splitting\") allowed device private PMDs to be split like THP mappings, but again did not update this code path. As a result, we might race a PMD split prior to acquiring the PMD lock. This patch addresses all of these issues by invoking check_pmd(), ensuring PMVW_MIGRATION is not set and checks whether a split raced us we do for PMD THP and migration entries. Instead of checking for a subset of the cases after taking the pmd_lock(), put device-private along with pmd_trans_huge() and pmd_is_migration_entry(). Also remove thp_migration_supported() as it is already guarded by pmd_is_migration_entry(). [akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68166", "url": "https://ubuntu.com/security/CVE-2026-68166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: prevent registration of special VMAs Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68170", "url": "https://ubuntu.com/security/CVE-2026-68170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix stale skb->sk reference on subflow close The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68177", "url": "https://ubuntu.com/security/CVE-2026-68177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Delay module ref count for \"enable_event\" trigger Triggers are now delayed from freeing, but can still be triggered until after the RCU grace period has ended. The freeing of the enable_event data is put into the private_data_free() callback, but the put of the module refcount is done immediately. It is possible that if a module is removed that has an event that would enable (or disable) it is still active, it can read the data of the module after it is removed causing a use-after-free bug. Move the trace_event_put_ref() that releases the module into the delayed callback so that the module can not be removed until any reference to its events are finished.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68191", "url": "https://ubuntu.com/security/CVE-2026-68191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix NULL pointer dereference in rhash table destroy When unbinding the ath12k driver, kernel NULL pointer dereferences occur in irq_work_sync() called from rhashtable_destroy(). Two hash tables are affected: 1. ath12k_link_sta hash table in ath12k_base 2. ath12k_dp_link_peer hash table in ath12k_dp The issue happens because the destroy functions are called unconditionally in cleanup paths, but the hash tables are only initialized late in their respective init functions. If the device was never fully started or if the init functions failed before initializing the hash tables, the pointers will be NULL. The issues are always reproducible from a VM because the MSI addressing initialization is failing. Call trace for ath12k_link_sta_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_link_sta_rhash_tbl_destroy+0x19/0x40 [ath12k] ath12k_core_stop+0xe/0x80 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Call trace for ath12k_dp_link_peer_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_dp_link_peer_rhash_tbl_destroy+0x29/0x50 [ath12k] ath12k_dp_cmn_device_deinit+0x21/0x140 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Fix this by adding NULL checks before calling rhashtable_destroy() in both destroy functions. The NULL check approach was chosen because the rhashtable pointer serves as the initialization state indicator. The init can fail at various points, leaving some components uninitialized. Checking the pointer directly is simpler than adding separate state flags that would need synchronization.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64586", "url": "https://ubuntu.com/security/CVE-2026-64586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: drain bus_reset work on device removal brcmf_fw_crashed() and the debugfs \"reset\" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs \"reset\" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. 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-68208", "url": "https://ubuntu.com/security/CVE-2026-68208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: Fix the error code of devm_kzalloc() in vip_probe_slice() In vip_probe_slice(), the error check for devm_kzalloc() incorrectly uses PTR_ERR_OR_ZERO() which returns 0 for NULL pointer. Return -ENOMEM for devm_kzalloc() failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68224", "url": "https://ubuntu.com/security/CVE-2026-68224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mali-c55: Fix possible ERR_PTR in enable_streams The media_pad_remote_pad_unique() function returns either a valid pointer or an ERR_PTR() on failure (-ENOTUNIQ if multiple links are enabled, -ENOLINK if no connected pad is found). The return value was assigned directly to isp->remote_src and dereferenced in the next line without checking for errors, which could lead to an ERR_PTR dereference. Add proper error checking with IS_ERR() before dereferencing the pointer. Also set isp->remote_src to NULL on error to maintain consistency with other error paths in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68237", "url": "https://ubuntu.com/security/CVE-2026-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: fix indefinite fence wait during GPU reset pre_reset only force-completes fences of MAPPED queues. A queue in any other state (e.g. mid-eviction) keeps its last_fence pending; after a GPU reset that fence never signals, so the eviction/suspend worker and process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and wedge the machine: INFO: task kworker/6:28 blocked for more than 120 seconds. Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu] Call Trace: dma_fence_wait_timeout+0x7e/0x130 amdgpu_userq_evict+0x67/0x140 [amdgpu] amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu] process_scheduled_works+0xa6/0x420 Force-complete every queue's fence regardless of state. The unmap and mark-hung step stays gated on MAPPED, since unmapping a queue that is not mapped is invalid. (cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68240", "url": "https://ubuntu.com/security/CVE-2026-68240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: publish dpagemap early to avoid device mapping leak on error drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68242", "url": "https://ubuntu.com/security/CVE-2026-68242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix NULL deref on sched_engine alloc failure Avoid using intel_context_put() before intel_context_init() in execlists_create_virtual() as the kref_put() inside would lead to NULL deref on the IOCTL path when sched_engine allocation fails. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68254", "url": "https://ubuntu.com/security/CVE-2026-68254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: require valid min/max vfreq for VRR Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68436", "url": "https://ubuntu.com/security/CVE-2026-68436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use kvzalloc to allocate struct dc struct dc has grown large over time (most of it the two inlined dc_scratch_space copies) and now sits close to the page allocator's 4 MiB contiguous allocation limit. Its actual size is not fixed by the source alone, it also depends on the compiler and the .config, so it can easily cross 4 MiB, e.g. with a newer GCC or a config change. dc_create() allocates it with kzalloc(). Once struct dc exceeds 4 MiB the request is rounded up to order 11 (8 MiB), which is above MAX_PAGE_ORDER, so the page allocator warns and returns NULL. dc_create() then fails, DM init fails and amdgpu probe aborts with -EINVAL: WARNING: mm/page_alloc.c:5197 at __alloc_frozen_pages_noprof+0x2f9/0x380 dc_create+0x38/0x660 [amdgpu] amdgpu_dm_init+0x2d9/0x510 [amdgpu] dm_hw_init+0x1b/0x90 [amdgpu] amdgpu_device_init.cold+0x150d/0x1e13 [amdgpu] amdgpu_driver_load_kms+0x19/0x80 [amdgpu] amdgpu_pci_probe+0x1e2/0x4c0 [amdgpu] dc_create() then returns NULL and DM init fails, which aborts the whole GPU init and makes amdgpu probe fail with -EINVAL (\"hw_init of IP block failed -22\"), leaving the display unusable. The subsequent amdgpu_irq_put() warnings during teardown are just fallout of unwinding a half-initialized device. struct dc is a software-only bookkeeping structure that is never handed to hardware DMA and is only ever kept as an opaque pointer, so it does not require physically contiguous memory. Allocate it with kvzalloc() (and free it with kvfree()) so that the allocator can fall back to vmalloc() when a contiguous allocation of that size is not available, which also avoids the MAX_PAGE_ORDER warning entirely. v2: - Rebase to amd-staging-drm-next. (cherry picked from commit 991e0516a8072f2292681c6ae98a924ab0e32575)", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68447", "url": "https://ubuntu.com/security/CVE-2026-68447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size from hardware without bounding it to the allocated BO region. If the HW field is larger than the queue's control stack allocation, memcpy reads past the BO into adjacent GTT memory and can leak kernel data to userspace. Store the page-aligned control stack BO size in mqd_manager and clamp checkpoint copies and reported checkpoint sizes to min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound for multi-XCC v9.4.3 checkpoint layout. (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3)", "cve_priority": "high", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68264", "url": "https://ubuntu.com/security/CVE-2026-68264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: Reset current_op in xe_pt_update_ops_init() xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it. After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind. Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry. Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(). v2 (Matt): - Add details in commit message. - Add Fixes tag and Cc to stable@vger.kernel.org (cherry picked from commit 046045543e530605c441063535e7dca0075369a6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68265", "url": "https://ubuntu.com/security/CVE-2026-68265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO's tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference (cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68267", "url": "https://ubuntu.com/security/CVE-2026-68267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists Unconditionally whitelisting OA registers is a security violation. Set RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers don't get whitelisted by default after probe, gt reset, resume and engine reset. (cherry picked from commit 90511bdcfda97211c01f1d945d4ea616578d8fca)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68273", "url": "https://ubuntu.com/security/CVE-2026-68273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68274", "url": "https://ubuntu.com/security/CVE-2026-68274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix buffer overflow in steered register list allocation The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt->fuse_topo.g_dss_mask, ...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68283", "url": "https://ubuntu.com/security/CVE-2026-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free freeing trigger private data Commit 61d445af0a7c (\"tracing: Add bulk garbage collection of freeing event_trigger_data\") moved the kfree() of event_trigger_data to a kthread that runs tracepoint_synchronize_unregister() before freeing. That removed the synchronization the trigger .free callbacks used to get implicitly and inline from trigger_data_free(). event_hist_trigger_free(), event_hist_trigger_named_free() and event_enable_trigger_free() free their satellite data (hist_data, cmd_ops, enable_data) right after trigger_data_free() returns. With the synchronization now deferred to the kthread, a concurrent tracepoint handler can still reach that data through the list_del_rcu()'d trigger, causing a use-after-free. The histogram teardown must stay synchronous: remove_hist_vars() and unregister_field_var_hists() have to detach a synthetic event from the histogram before the trigger-removal write returns, otherwise a following command races in and the synthetic-event removal fails with -EBUSY, as the trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait with the correct barrier - tracepoint_synchronize_unregister(), matching the free kthread - before freeing. The enable trigger has no such synchronous requirement, and a blocking synchronize there would re-serialize the path that commit deliberately deferred. Give it an optional private_data_free() callback that the free kthread runs after its grace period, and free enable_data from there.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68286", "url": "https://ubuntu.com/security/CVE-2026-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68287", "url": "https://ubuntu.com/security/CVE-2026-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix size calculations for 64-bit attributes net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68288", "url": "https://ubuntu.com/security/CVE-2026-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68289", "url": "https://ubuntu.com/security/CVE-2026-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68291", "url": "https://ubuntu.com/security/CVE-2026-68291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix max_vport related crash on allocation error during init Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000 [ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000 [ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20 [ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000 [ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0 [ 320.417385] PKRU: 55555554 [ 320.417398] Call Trace: [ 320.417412] [ 320.417429] pci_device_remove+0x42/0xb0 [ 320.417459] device_release_driver_internal+0x1a9/0x210 [ 320.417492] driver_detach+0x4b/0x90 [ 320.417516] bus_remove_driver+0x70/0x100 [ 320.417539] pci_unregister_driver+0x2e/0xb0 [ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0 [ 320.417592] ? kmem_cache_free+0x31e/0x550 [ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190 [ 320.417644] ? do_syscall_64+0x38/0x6b0 [ 320.417665] do_syscall_64+0xc8/0x6b0 [ 320.417683] ? clear_bhb_loop+0x30/0x80 [ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 320.417727] RIP: 0033:0x7f963bb30beb", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68303", "url": "https://ubuntu.com/security/CVE-2026-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hvs/v3d: Fix null dereference in unbind The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68312", "url": "https://ubuntu.com/security/CVE-2026-68312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and cifs_close_deferred_file_under_dentry(), when a pending deferred close is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to add the file to the local processing list may fail under memory pressure. The loop breaks immediately, but the cancelled work is no longer pending (it would have called _cifsFileInfo_put()), and the cfile is never added to file_head for processing. The cifsFileInfo reference and the open server handle both leak. Fix by saving the cfile that failed allocation in a local variable, breaking as before, and calling _cifsFileInfo_put() on it after releasing the lock. Any files later in the iteration are unaffected since their deferred work is still pending and will fire normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68316", "url": "https://ubuntu.com/security/CVE-2026-68316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Fix element size accounting for cmd stream validation There are 2 issues with the element size handling in the command stream validation which result in too small of a size calculated when the element size is 16/32/64 bits. For NHWC format, the element size is simply missing from the calculation. The bitfield for the element size is different between IFM/IFM2 and OFM. IFM and IFM2 encode the precision in parameter bits 2:3, while OFM uses bits 1:2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68440", "url": "https://ubuntu.com/security/CVE-2026-68440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix heap overflow when reading module EEPROM txgbe_read_eeprom_hostif() always copies round_up(length, 4) bytes into the caller buffer, which ethtool allocates with exactly 'length' bytes. A non-4-aligned length therefore causes an out-of-bounds write. Copy only the remaining bytes on the final dword instead.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68323", "url": "https://ubuntu.com/security/CVE-2026-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: serialize udp bearer replicast list updates tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68441", "url": "https://ubuntu.com/security/CVE-2026-68441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected. This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d (\"bpf: add bpf_redirect() helper\"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available. commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs. Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a wrapper around tcf_classify() for use by qdisc classify functions and tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT, the wrapper converts it to TC_ACT_SHOT, dropping the packet rather than letting it continue silently. Dropping is preferred over letting the packet through because the user immediately sees packet loss. Silently passing the packet through would hide the problem and leave the user wondering why their redirect is not working. The clsact fast path, tc_run() continues to call tcf_classify() directly and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by sch_handle_egress/ingress() calling skb_do_redirect() as before.", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68337", "url": "https://ubuntu.com/security/CVE-2026-68337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject redirect helpers without a bpf_net_context The bpf_redirect*() helpers and skb_do_redirect() obtain the per-task bpf_redirect_info via bpf_net_ctx_get_ri(), which dereferences the current->bpf_net_context unconditionally. That context is established on the paths that run tc BPF such as sch_handle_{ingress,egress}(), *except* for the case where {cls,act}_bpf was attached to a proper qdisc. A program running from there reaches the NULL deref in two ways: * It calls bpf_redirect() directly, which dereferences the context at the top of the helper: tc qdisc add dev eth0 root handle 1: red limit 1MB min 10KB max 20KB \\ avpkt 1000 burst 100 qevent early_drop block 10 tc filter add block 10 pref 1 bpf obj redirect.o * It simply returns TC_ACT_REDIRECT without helper call: tcf_qevent_handle() then dispatches to skb_do_redirect(), which dereferences the context Rather than extending bpf_net_context management into the qdisc path, make the redirect helpers refuse to operate when no context exists, and have tcf_qevent_handle() drop a TC_ACT_REDIRECT verdict instead of calling skb_do_redirect(). Previous behaviour was a crash, so nothing regresses by not supporting it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68345", "url": "https://ubuntu.com/security/CVE-2026-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm_mpam: guard MBWU state before adding it to garbage __destroy_component_cfg() adds each RIS mbwu_state object to the MPAM garbage list when destroying component configuration. However, mbwu_state is allocated per RIS and only for RISes with MBWU monitors. A component can therefore have comp->cfg allocated while some RISes still have ris->mbwu_state set to NULL. Passing a NULL mbwu_state to add_to_garbage() dereferences the NULL pointer inside the macro. Skip RISes that do not have an mbwu_state object before adding them to the garbage list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68347", "url": "https://ubuntu.com/security/CVE-2026-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68375", "url": "https://ubuntu.com/security/CVE-2026-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle partially initialized auxiliary devices bnxt_aux_devices_init() calls auxiliary_device_init() before all fields used by bnxt_aux_dev_release() are initialized. After auxiliary_device_init() succeeds, later errors must unwind with auxiliary_device_uninit(), which invokes the release callback. The release callback assumes that aux_priv->id, aux_priv->edev, edev->net and edev->ulp_tbl are all populated. If allocation fails after auxiliary_device_init(), the release path can otherwise dereference or clear partially initialized state. Allocate and attach the bnxt_en_dev and ULP table before calling auxiliary_device_init(), so the release callback only sees a fully initialized auxiliary private object. If auxiliary_device_init() itself fails, free those allocations directly because device_initialize() has not run and the release callback will not be invoked. 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-68382", "url": "https://ubuntu.com/security/CVE-2026-68382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Hold device ref until queue teardown completes GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock. Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending. Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work. With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. Replace the fini wait with an assertion and remove the unused fini_wq. v2: - Rebase v3: - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt) - Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt) - Drop separate deferred drm_dev_put worker. - Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini(). v4: - Replace the guc_submit_sw_fini() wait with an assertion and remove the now-unused fini_wq. (sashiko) v5: - Move destroy work to a module-lifetime Xe workqueue instead of system_dfl_wq. (Matt) - Flush the module-lifetime destroy workqueue during PCI remove to preserve the old device-remove wait semantics. v6: - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid letting it outlive the xe_device/drm_device. (Sashiko) - Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work can be queued from the reclaim path. v7: - Drop the per-device xe->destroy_wq and use the module-level destroy WQ for SVM pagemap destroy as well. (Matt) - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*() helpers because the WQ is no longer exec-queue specific. (Matt) v8: - Rebase. v9: - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM destroy_wq because it can be queued from reclaim and embeds the dev_pagemap used by devres teardown. (Sashiko) - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM from it. - Update the module-WQ kdoc to document the GuC/SVM split. v10: - Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the workqueue allocation warning. v11: - Drop the SVM pagemap destroy comment as it was revision-specific. (Thomas) v12: - Rebase. (cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68383", "url": "https://ubuntu.com/security/CVE-2026-68383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Keep scheduler timeline name alive The scheduler keeps a pointer to the timeline name, but q->name is freed with the exec queue while scheduler fences can still reference it. Store the name in struct xe_guc_exec_queue so it shares the scheduler's RCU-deferred lifetime. (cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68390", "url": "https://ubuntu.com/security/CVE-2026-68390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups hci_conn_params_lookup requires hdev->lock be held, otherwise the list iteration or param access is not safe. Hold hdev->lock for params lookups in hci_sync.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-2026-68404", "url": "https://ubuntu.com/security/CVE-2026-68404", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: use wiphy work for socket owner autodisconnect nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68367", "url": "https://ubuntu.com/security/CVE-2026-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: synchronize delayed set_alt with teardown The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68095", "url": "https://ubuntu.com/security/CVE-2026-68095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse-uring: fix race between registration and connection abortion This fixes this race: - thread a: io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref yet - thread b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() is a no-op due to queue ref being 0 - thread a: grabs the queue_ref, queue_ref is now 1, rest of fuse_uring_do_register() logic executes - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs and calls \"wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);\" The abort/unmount thread will hang indefinitely in unkillable state as nothing will decrement queue_refs or wake stop_waitq, and the ring, queue, and ent are leaked. Fix this by checking fch->connected under fch->lock after the created ent has grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either release the queue ref and wake up stop_waitq (in case fuse_chan_wait_aborted() is already waiting) in fuse_uring_do_register() when we detect !fch->connected, or if the connection is aborted after the check, it is guaranteed that the async teardown worker will be running in the background cleaning up ents and decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-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-68173", "url": "https://ubuntu.com/security/CVE-2026-68173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: wait on ublk_dev_ready() instead of ub->completion ub->completion is only re-armed by a successful START_USER_RECOVERY. If the ublk server sends END_USER_RECOVERY without one - e.g. its START failed with -EBUSY and the error was ignored - the wait is satisfied by the stale completion of the previous recovery cycle, and the device is marked LIVE and the requeue list kicked while the FETCH stream is still running and ubq->canceling is still set. The kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it again via __ublk_abort_rq(), and after the last FETCH clears ->canceling nothing ever kicks the requeue list again: the request is stranded there while holding its tag. If it is the flush machinery's flush_rq, every subsequent fsync piles up in uninterruptible sleep and teardown hangs on tag draining. This matches a report of a lost PREFLUSH with ext4 on top of ublk after daemon crash recovery. ub->completion is an edge-triggered latch used as a proxy for the level condition \"every queue has fetched all I/O commands\", which can regress (F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop it and wait on the real condition instead: the new helper ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then re-checks it under ub->mutex, waiting again on regression, and returns with the mutex held and readiness guaranteed. Readiness becomes true in the same ub->mutex critical section that clears the last queue's ->canceling, so END_USER_RECOVERY marks the device LIVE and kicks the requeue list strictly after ->canceling clears. The wait stays interruptible, so a server whose daemon died can still be signalled out. For ublk_ctrl_start_dev() this replaces the fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting until the device is ready again.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68113", "url": "https://ubuntu.com/security/CVE-2026-68113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68118", "url": "https://ubuntu.com/security/CVE-2026-68118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: challenge ACK for non-exact RST in SYN-RECEIVED The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68120", "url": "https://ubuntu.com/security/CVE-2026-68120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtase: Workaround for TX hang caused by hardware packet parsing The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission.", "cve_priority": "medium", "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-68122", "url": "https://ubuntu.com/security/CVE-2026-68122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix peer refcount leak in TCP error paths When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&peer->tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object. The race window: CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error): ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2 schedule_work() <- queued schedule_work() <- NO-OP (work already pending) ovpn_tcp_peer_del_work runs: ovpn_peer_del() ovpn_peer_put() <- refcnt+1 <- peer never freed Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68128", "url": "https://ubuntu.com/security/CVE-2026-68128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: reject out-of-range ptype in ice_parser_profile_init set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from providing ptype >= 1024 through VIRTCHNL, resulting in a write past the end of the bitmap and a kernel page fault. Reproduced with a custom kernel module injecting a crafted VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1. crash_parser: ice_parser_profile_init @ ffffffffc0d61b60 crash_parser: setting ptype=0xffff (max valid=1023) crash_parser: calling ice_parser_profile_init -- expect OOB crash! BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace: ? __pfx_ice_parser_profile_init+0x10/0x10 [ice] crash_init+0x127/0xff0 [crash_parser] do_one_initcall+0x45/0x310 do_init_module+0x64/0x270 init_module_from_file+0xcc/0xf0 idempotent_init_module+0x17b/0x280 __x64_sys_finit_module+0x6e/0xe0 Bail out early with -EINVAL when ptype is out of range.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68132", "url": "https://ubuntu.com/security/CVE-2026-68132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: super: fix emergency thaw deadlock on frozen block devices do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68133", "url": "https://ubuntu.com/security/CVE-2026-68133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP Call Trace during PTP release If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will result in the following PTP release call trace during driver unload: kernel BUG at lib/list_debug.c:52! ice_ptp_release+0x332/0x3c0 [ice] ice_deinit_features.part.0+0x10e/0x120 [ice] ice_remove+0x100/0x220 [ice] This was observed when passing PF1 through to a VM. ice_ptp_init() fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT. Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and returning without error, preventing the invalid state transition to ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from ICE_PTP_RESETTING after a failed rebuild.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68134", "url": "https://ubuntu.com/security/CVE-2026-68134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: ptp_s390: Add missing facility check Only register the physical clock when facility 28 is installed and PTFF QAF returns that PTFF QPT is available.", "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-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-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-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-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-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-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-68150", "url": "https://ubuntu.com/security/CVE-2026-68150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/super: fix emergency thaw double-unlock of s_umount do_thaw_all() iterates over all superblocks via __iterate_supers() with SUPER_ITER_EXCL, which acquires s_umount exclusively before calling the callback and releases it afterwards. However, the callback do_thaw_all_callback() calls thaw_super_locked() which unconditionally releases s_umount on every code path. This results in a second unlock attempt in __iterate_supers() that corrupts the rwsem state, triggering a DEBUG_RWSEMS warning: [ 182.601148] sysrq: Emergency Thaw of all frozen filesystems [ 182.601865] ------------[ cut here ]------------ [ 182.602375] DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff99b1011e5870, owner = 0x0, curr 0xffff99b101b06c80, list not empty [ 182.603817] WARNING: kernel/locking/rwsem.c:1412 at up_write+0xa3/0x170, CPU#2: kworker/2:1/53 [ 182.604578] Modules linked in: [ 182.604864] CPU: 2 UID: 0 PID: 53 Comm: kworker/2:1 Not tainted 7.2.0-rc4-00001-gbd3bd93ea98a-dirty #4 PREEMPT(lazy) [ 182.605711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014 [ 182.606417] Workqueue: events do_thaw_all [ 182.606750] RIP: 0010:up_write+0xaf/0x170 [ 182.607076] Code: 19 3a 92 48 0f 44 c2 48 8b 55 08 48 8b 55 00 4c 8b 45 08 48 8b 55 00 48 8d 3d ad 91 e0 01 48 8b 4d 20 50 48 c7 c6 f0 8c 26 92 <67> 48 0f b9 3a e8 d7 93 4e 00 58 eb 81 48 83 7f 18 00 48 c7 c2 8d [ 182.608563] RSP: 0018:ffffb670001d7e08 EFLAGS: 00010246 [ 182.609007] RAX: ffffffff92349e8d RBX: 0000000000000000 RCX: ffff99b1011e5870 [ 182.609595] RDX: 0000000000000000 RSI: ffffffff92268cf0 RDI: ffffffff92914d10 [ 182.610283] RBP: ffff99b1011e5870 R08: 0000000000000000 R09: ffff99b101b06c80 [ 182.610847] R10: ffff99b10139a808 R11: fefefefefefefeff R12: 0000000000000000 [ 182.611414] R13: ffffffff90cf74d0 R14: 0000000000000000 R15: ffff99b1011e5800 [ 182.612009] FS: 0000000000000000(0000) GS:ffff99b1eaaee000(0000) knlGS:0000000000000000 [ 182.612670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 182.613146] CR2: 00000000005c631c CR3: 00000000013ee000 CR4: 00000000000006f0 [ 182.613722] Call Trace: [ 182.613946] [ 182.614130] __iterate_supers+0x128/0x150 [ 182.614463] do_thaw_all+0x1b/0x30 [ 182.614759] process_scheduled_works+0xbb/0x3f0 [ 182.615150] ? __pfx_worker_thread+0x10/0x10 [ 182.615499] worker_thread+0x129/0x270 [ 182.615816] ? __pfx_worker_thread+0x10/0x10 [ 182.616201] kthread+0xe2/0x120 [ 182.616469] ? __pfx_kthread+0x10/0x10 [ 182.616792] ret_from_fork+0x15b/0x240 [ 182.617115] ? __pfx_kthread+0x10/0x10 [ 182.617426] ret_from_fork_asm+0x1a/0x30 [ 182.617761] [ 182.617968] ---[ end trace 0000000000000000 ]--- [ 182.618412] Emergency Thaw complete Fix this by switching to SUPER_ITER_UNLOCKED and acquiring s_umount in the callback via super_lock_excl() before calling thaw_super_locked(). This matches the locking pattern expected by thaw_super_locked() and eliminates the double unlock. While at it, remove the dead 'return;' at the end of do_thaw_all_callback().", "cve_priority": "low", "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-68152", "url": "https://ubuntu.com/security/CVE-2026-68152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: fix use-after-free in AMT delayed works When an AMT device is removed, pending delayed works can still access the freed amt_dev structure, which may result in kernel crashes or memory corruption. amt_dev_stop() cancels req_wq and discovery_wq with cancel_delayed_work_sync(), but these works can be scheduled again from event_wq after the cancellation. This allows delayed works to access the freed amt_dev structure after the netdev has been released. The following is a simple race scenario: CPU0 CPU1 amt_dev_stop() cancel_delayed_work_sync() amt_event_work() mod_delayed_work(req_wq) free netdev req_wq accesses freed amt_dev Use disable_delayed_work_sync() in amt_dev_stop() to prevent req_wq and discovery_wq from being queued again and wait for running work items to complete. The delayed works are disabled after initialization in amt_newlink() and enabled only when the device is successfully opened. This keeps the delayed work lifecycle synchronized with the lifetime of the AMT device.", "cve_priority": "high", "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-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-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-68168", "url": "https://ubuntu.com/security/CVE-2026-68168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix afs_edit_dir_remove() to get, not find, block 0 Fix afs_edit_dir_remove() to use afs_dir_get_block() to get block 0 rather than afs_dir_find_block() as the latter caches the found block in the afs_dir_iter and may[*] switch out the page it's on if another afs_dir_find_block() is done. This parallels what afs_edit_dir_add() does. [*] There's more than one block per page.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68169", "url": "https://ubuntu.com/security/CVE-2026-68169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: userspace: fix use-after-free in get_local_id In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a \"not found\" sentinel.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68172", "url": "https://ubuntu.com/security/CVE-2026-68172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: make huge_ptep_get handled unaligned addresses huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma). The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned. On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map or into a hole, dereference a VA not mapped into the kernel pgtables and cause kernel panic. Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68174", "url": "https://ubuntu.com/security/CVE-2026-68174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix union collision of module and refcnt for dynamic events In 'struct trace_event_call', the 'module' pointer and the 'refcnt' atomic variable share the same memory space in a union. For dynamic events, the union member is 'refcnt', which acts as an active reference counter. When a dynamic event (such as kprobe, uprobe, fprobe, eprobe, or wprobe) has a non-zero reference count (e.g. due to active event triggers or perf attachments), its 'call->module' evaluates to a small non-zero integer instead of NULL. When filtering or setting events for a specific module (e.g., writing ':mod:' to 'set_event'), the code in '__ftrace_set_clr_event_nolock()' and 'update_event_fields()' reads 'call->module' directly without checking whether the event is dynamic. This causes the kernel to treat the small integer (refcnt) as a 'struct module' pointer, leading to a NULL/invalid pointer dereference (Oops) when dereferencing the module name. Fix this by ensuring that the 'TRACE_EVENT_FL_DYNAMIC' flag is checked before treating 'call->module' as a valid pointer in these code paths.", "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-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-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-68434", "url": "https://ubuntu.com/security/CVE-2026-68434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms Commit b1b4efea05a5 (\"serial: 8250_mid: Disable DMA for selected platforms\") replaced the dnv_board setup and exit callbacks with PTR_IF(false, ...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. Fix this by adding the missing NULL checks before calling the setup and exit callbacks.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17: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-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-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16: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-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-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-68198", "url": "https://ubuntu.com/security/CVE-2026-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix use-after-free in aggr_reset_state() The aggr_reset_state() function uses timer_delete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggr_module_destroy(). If the timer callback (aggr_timeout) is executing when aggr_reset_state() is called, the callback will continue to access aggr_conn fields like rx_tid[] and stat[] which may be freed immediately after by kfree(aggr_info->aggr_conn) in aggr_module_destroy(). Additionally, the timer callback can re-arm itself via mod_timer() while aggr_reset_state() is running, creating a more complex race condition. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "high", "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-68200", "url": "https://ubuntu.com/security/CVE-2026-68200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: don't re-enter an instance callback that is still running The userspace-driven timer (utimer) TRIGGER ioctl calls snd_timer_interrupt() directly with no serialization, so two threads triggering the same utimer can run snd_timer_interrupt() on one snd_timer concurrently. snd_timer_process_callbacks() drops timer->lock around each instance callback and marks the in-flight callback with the single SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that bit to drain an in-flight callback before freeing the instance. The bit cannot represent two concurrent callbacks: when a second interrupt re-queues an instance whose callback is still running, both run at once, the first to finish clears the bit, and the close-path drain then frees the instance (and its callback_data) while the other callback is still live - a use-after-free reachable by any user able to open /dev/snd/timer, both via a user timer instance and via a sequencer queue timer bound to the utimer. snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so a concurrent interrupt already observes it under the lock. Skip re-queuing an instance (and its slaves) to the ack/sack list while its callback is in flight; the accumulated pticks are delivered on the next tick, so no event is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68201", "url": "https://ubuntu.com/security/CVE-2026-68201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: drain a slave's callback before its master detaches it snd_timer_close_locked() drains the closing instance's own in-flight callback (IFLG_CALLBACK) before freeing it, but not its slaves'. When a master instance is closed, remove_slave_links() clears each slave's ->timer; the slave's own close then reads timer == NULL and takes the branch that skips the drain entirely (snd_timer_stop_slave() also no-ops on a NULL timer). So a slave whose callback is still running when the master is closed is freed underneath the live callback, leading to use-after-free. Drain the slaves too before remove_slave_links() severs them. snd_timer_stop() has already taken this instance off the active list, so no new slave callback can be queued. Take the slaves off the ack list so a pending one can't fire either, then wait for any that is already in flight.", "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-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-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-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-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-68211", "url": "https://ubuntu.com/security/CVE-2026-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32-dcmipp: 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. dcmipp_bytecap_start_streaming() returned -EINVAL when the source subdevice could not be resolved from the media graph, before pm_runtime_resume_and_get() and media_pipeline_start() had been called. The remaining error paths already converge on the err_buffer_done label, which calls dcmipp_bytecap_all_buffers_done(..., VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate err_pm_put / err_media_pipeline_stop 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": "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-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-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-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-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-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-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-68230", "url": "https://ubuntu.com/security/CVE-2026-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: amlogic-c3: Add validations for ae and awb config Avoid invalid memory access if the zones_num is bigger than zone_weight. This patch fixes the following smatch errors: drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max", "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-68232", "url": "https://ubuntu.com/security/CVE-2026-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path.", "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-68233", "url": "https://ubuntu.com/security/CVE-2026-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Shut down BO cache timer before teardown The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20: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-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-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-68238", "url": "https://ubuntu.com/security/CVE-2026-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Release VFCT ACPI table reference amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68239", "url": "https://ubuntu.com/security/CVE-2026-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Account for NULL and handle pages in ttm_pool_backup Pages in ttm_pool_backup can be NULL or backup handles (ttm_backup_page_ptr_is_handle()), neither of which can be passed to set_pages_array_wb() or freed. Add a dedicated WB pass before the dma/purge loop that walks allocations using the same i += num_pages stride, skipping NULL and handle entries, and calls set_pages_array_wb() once per contiguous run of real pages. Apply the same NULL/handle guard to the dma/purge loop. Fixes the following oops: Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI RIP: 0010:__cpa_process_fault+0xf8/0x770 RSP: 0018:ffffc90000a87718 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34 RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0 R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000 R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0 FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0 PKRU: 55555554 Call Trace: __change_page_attr_set_clr+0x989/0xe90 ? __purge_vmap_area_lazy+0x6c/0x3a0 ? _vm_unmap_aliases+0x250/0x2a0 set_pages_array_wb+0x7f/0x120 ttm_pool_backup+0x4c9/0x5b0 [ttm] ? dma_resv_wait_timeout+0x3b/0xf0 ttm_tt_backup+0x32/0x60 [ttm] ttm_bo_shrink+0x66/0x110 [ttm] xe_bo_shrink_purge+0x12b/0x1b0 [xe] xe_bo_shrink+0xbb/0x270 [xe] __xe_shrinker_walk+0xf7/0x160 [xe] xe_shrinker_walk+0x9d/0xc0 [xe] xe_shrinker_scan+0x11f/0x210 [xe] do_shrink_slab+0x13b/0x270 shrink_slab+0xf1/0x400 shrink_node+0x352/0x8a0 balance_pgdat+0x32c/0x700 kswapd+0x205/0x2f0 ? __pfx_autoremove_wake_function+0x10/0x10 ? __pfx_kswapd+0x10/0x10 kthread+0xd1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1b1/0x200 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68241", "url": "https://ubuntu.com/security/CVE-2026-68241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/mst: limit DP MST ESI service loop The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto. (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)", "cve_priority": "medium", "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-68245", "url": "https://ubuntu.com/security/CVE-2026-68245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only valid while the lock is still being held. Once xa_unlock_irqrestore is called and returned, the pointer is no longer under lock and is subject to modification. Since, the caller still dereferences vm->task_info in amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a use after unlock problem. Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid() through removing the amdgpu_vm_get_vm_from_pasid() function from amdgpu_vm.c and making the relevant code inline to hold the lock while it is still in use. (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)", "cve_priority": "high", "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-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-68252", "url": "https://ubuntu.com/security/CVE-2026-68252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68253", "url": "https://ubuntu.com/security/CVE-2026-68253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)", "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-68257", "url": "https://ubuntu.com/security/CVE-2026-68257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix 32-bit overflow in CWSR total size calculation total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68258", "url": "https://ubuntu.com/security/CVE-2026-68258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on CRIU restore queue type and mqd size We weren't checking whether the values provided in the private data in kfd CRIU restore were within bounds. For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it. For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations. (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)", "cve_priority": "low", "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-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-68266", "url": "https://ubuntu.com/security/CVE-2026-68266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68268", "url": "https://ubuntu.com/security/CVE-2026-68268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Return error on non-migratable faults requiring devmem Non-migratable faults that require devmem incorrectly jump to the 'out' label, which squashes the error code intended to be returned to the upper layers. Fix this by returning -EACCES instead. (cherry picked from commit c4508edb2c723de93717272488ea65b165637eac)", "cve_priority": "medium", "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-68270", "url": "https://ubuntu.com/security/CVE-2026-68270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Avoid possible truncation with calculating visible size Calculating the visible size of the system framebuffer can result in truncation of the result. The calculation uses 32-bit arithmetics, which can overflow if the values for height and stride are large. Fix the issue by multiplying with mul_u32_u32().", "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-68275", "url": "https://ubuntu.com/security/CVE-2026-68275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks up the bo_va for the buffer object in the caller's VM via amdgpu_vm_bo_find(), but uses the returned pointer without checking it. amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM, which is the normal case for a BO that has never been mapped. The result is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which expands to list_for_each_entry(mapping, &(bo_va)->valids, list) and dereferences bo_va, causing a NULL pointer dereference. This is reachable by any process able to issue the ioctl (render group) simply by requesting mapping info for an unmapped BO. Return -ENOENT when no bo_va is found, jumping to out_exec so the drm_exec context and GEM object reference are released. (cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68276", "url": "https://ubuntu.com/security/CVE-2026-68276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx: fix cleaner shader IB buffer overflow The cleaner shader sysfs path allocates a 16-dword (64 byte) IB but incorrectly fills (align_mask + 1) dwords. On GFX rings align_mask is 0xff, so the loop wrote 256 dwords into a 64-byte buffer, causing a kernel page fault. The IB only needs to be a minimal NOP shell to schedule the job; the cleaner shader itself is emitted on the ring via emit_cleaner_shader(). Fill 16 dwords to match the allocation. v2: Use ib_size_dw variable (Lijo) (cherry picked from commit bf21af331ebf72d0935fd70c73192414a422c03a)", "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-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-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-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-68282", "url": "https://ubuntu.com/security/CVE-2026-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: analogix_dp: Add missing error check for platform_get_resource() Add missing error check for platform_get_resource() return value to prevent NULL pointer dereference when memory resource is not available.", "cve_priority": "medium", "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-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-68292", "url": "https://ubuntu.com/security/CVE-2026-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues.", "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-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-68296", "url": "https://ubuntu.com/security/CVE-2026-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM Before commit 00d066a4d4ed (\"netdev_features: convert NETIF_F_LLTX to dev->lltx\"), NETIF_F_LLTX was set unconditionally in both __gre_tunnel_init() and ip6gre_tnl_init_features() alongside GRE_FEATURES: dev->features |= GRE_FEATURES | NETIF_F_LLTX; When that commit converted NETIF_F_LLTX to the dev->lltx flag, it placed 'dev->lltx = true' after the SEQ/CSUM early returns instead of before them. This causes GRE/GRETAP/ip6gre tunnels with SEQ or CSUM+encap to lose lockless TX, reintroducing _xmit_lock acquisition around their ndo_start_xmit. Since GRE xmit re-enters the stack via ip_tunnel_xmit(), holding _xmit_lock risks ABBA deadlock with the underlay device. CPU0 CPU1 ---- ---- lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); Fix by moving dev->lltx = true before the early returns in both functions, restoring the original unconditional behavior.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64575", "url": "https://ubuntu.com/security/CVE-2026-64575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: fix double sock release on batch realloc bpf_iter_tcp_batch() releases the current batch via bpf_iter_tcp_put_batch(), which drops the socket refs and rewrites each slot with the socket cookie, then grows the batch. cur_sk/end_sk are kept for bpf_iter_tcp_resume(), but on realloc failure the function returns ERR_PTR() before resume runs, leaving cur_sk < end_sk over slots that now hold cookies rather than sock pointers. bpf_iter_tcp_seq_stop() then calls bpf_iter_tcp_put_batch() again and dereferences a cookie as a struct sock. Empty the batch on the failure path so stop() does not release it again. The sockets were already freed by the first bpf_iter_tcp_put_batch(), so nothing leaks, and a later read() rescans the bucket from the start instead of skipping it. The sibling GFP_NOWAIT failure path still holds real socket references and is left for stop() to release. BUG: KASAN: null-ptr-deref in __sock_gen_cookie Read of size 8 at addr 0000000000000059 by task exploit ... __sock_gen_cookie (net/core/sock_diag.c:28) bpf_iter_tcp_put_batch (net/ipv4/tcp_ipv4.c:2918) bpf_iter_tcp_seq_stop (net/ipv4/tcp_ipv4.c:3270) bpf_seq_read (kernel/bpf/bpf_iter.c:205) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 entry_SYSCALL_64_after_hwframe Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68298", "url": "https://ubuntu.com/security/CVE-2026-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create() Commit 9e9787414882 (\"drm/xe/userptr: replace xe_hmm with gpusvm\") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a \"simple\" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). (cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4)", "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-68448", "url": "https://ubuntu.com/security/CVE-2026-68448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: check access to copy_file_range source with src mounter creds Commit 5dae222a5ff0c (\"vfs: allow copy_file_range to copy across devices\") allowed filesystems that implement the copy_file_range() f_op to decide if they want to access cross-sb copy from/to the same fs type. The same commit added checks to verify same sb copy for filesystems that implement ->copy_file_range() and do not support cross-sb copy at the time, namely, to ceph, fuse and nfs. The two remaining fs which implement ->copy_file_range(), cifs and overlayfs started to support cross-sb copy from this time. While overlayfs does support cross-sb copy when the two underlying files are on the same base fs, the copy operation on the two real files from two different overalyfs filesystems is performed with the mounter creds of the destination overlayfs and the read permission access hook for the source file was called with the wrong creds. This could cause either deny of access to copy which would otherwise be allowed (e.g. with splice) or allow read access to file which would otherwise be denied. Fix the latter case by explicitly verifying read access to source file with the source overlayfs mounter creds. The former case remains a quirk of cross-sb overlayfs copy, but userspace could fall back to regular copy so no harm done.", "cve_priority": "low", "cve_public_date": "2026-08-12 01:17: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-68307", "url": "https://ubuntu.com/security/CVE-2026-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix crash in reset link replay During reset recovery, mt7925_vif_connect_iter() replays firmware state for links tracked in mvif->valid_links. After MLO link changes or MCU timeout recovery, the driver bitmap can temporarily contain a link whose mac80211 bss_conf has already gone away. This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching the crash where x1, the second argument, is NULL: pc : mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] lr : mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] x2 : ffffff80a77f6018 x1 : 0000000000000000 x0 : ffffff8099402080 Call trace: mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common] Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA reset replay is unchanged because the helper still returns &vif->bss_conf for the legacy link.", "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-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-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-68311", "url": "https://ubuntu.com/security/CVE-2026-68311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: guard link STA in decap offload mt7925_sta_set_decap_offload() iterates over the vif valid_links mask when updating decap offload state for an MLO station. The station may not have a link STA for every valid link of the vif, so mt792x_sta_to_link() can return NULL for a link that belongs to the vif but not to the station. The function currently dereferences mlink before checking whether the link WCID is ready. If mlink is NULL, setting or clearing MT_WCID_FLAG_HDR_TRANS dereferences a NULL pointer. Skip links without a station link before touching mlink->wcid.", "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-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-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-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-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-68321", "url": "https://ubuntu.com/security/CVE-2026-68321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix FDIR filter leak on remove Perfect FDIR filters can be added while the interface is down and are kept on the software list for later restore. unregister_netdev() only calls ndo_stop when the device is up, so txgbe_fdir_filter_exit() in txgbe_close() is skipped in that case and the filters are leaked on driver remove. Free the filter list from txgbe_remove() as well.", "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-68330", "url": "https://ubuntu.com/security/CVE-2026-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix DMA direction for NPU mailbox buffer airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE, but some callers expect the NPU to write response data back into the same buffer: - airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into the buffer, then the caller reads it via memcpy() - airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back npu_stats_addr field in the response On non-cache-coherent architectures like EN7581 (Cortex-A53 without hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op — it does not invalidate the CPU cache. If the NPU-written cache line is still present in the CPU cache when the caller reads the buffer, the CPU observes stale data instead of the NPU response. This is a timing-sensitive bug: small mailbox buffers (~24 bytes) typically fit in a single cache line and may survive in the cache until the caller reads them, producing silent data corruption rather than a crash. The bug is more likely to trigger when the caller reads the response immediately after dma_unmap_single() without intervening cache-evicting operations. Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures dma_unmap_single() invalidates the CPU cache on non-coherent systems. The mailbox buffers are small so there is no performance concern.", "cve_priority": "low", "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-68332", "url": "https://ubuntu.com/security/CVE-2026-68332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix potential use-after-free in airoha_ppe_deinit() airoha_ppe_deinit() replaces the NPU pointer with NULL via rcu_replace_pointer() but does not wait for existing RCU readers to exit before calling ppe_deinit() and airoha_npu_put(). This can cause a use-after-free if a reader in an RCU read-side critical section still holds a reference to the NPU when it is freed. The init path (airoha_ppe_init) already calls synchronize_rcu() after rcu_assign_pointer(), but the deinit path introduced in commit 6abcf751bc08 (\"net: airoha: Fix schedule while atomic in airoha_ppe_deinit()\") omitted the matching barrier when switching from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer(). Add synchronize_rcu() before ppe_deinit() to ensure all existing RCU readers have completed before the NPU resources are released.", "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-68334", "url": "https://ubuntu.com/security/CVE-2026-68334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix io_thread race in rxrpc_wake_up_io_thread() rxrpc_wake_up_io_thread() checks local->io_thread before waking it, but then reloads the pointer for wake_up_process(). local->io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so the second load can see NULL even if the first load did not. Take a READ_ONCE() snapshot and use it for both the NULL check and the wake_up_process() call, as rxrpc_encap_rcv() already does.", "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-68341", "url": "https://ubuntu.com/security/CVE-2026-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix use after free in unlock_ovpn() unlock_ovpn() iterates over the release_list using llist_for_each_entry() and drops the peer reference inside the loop body via ovpn_peer_put(). If this drops the last reference, the peer is eventually freed. However, llist_for_each_entry() reads peer->release_entry.next in the loop advance expression, which runs after the body. By that time the peer may have already been freed, resulting in a use after free when advancing to the next list entry. Fix this by using llist_for_each_entry_safe(), which caches the next pointer before executing the loop body.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68342", "url": "https://ubuntu.com/security/CVE-2026-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: avoid putting unrelated P2P peer on socket release ovpn_peer_release_p2p() is called when an OVPN UDP socket is being destroyed. It checks the currently published P2P peer and releases it only if that peer still uses the socket being destroyed. A peer replacement can publish a new peer before the old UDP socket is destroyed. When the old socket destruction path runs afterwards, ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the new peer uses a different socket, the function takes the socket mismatch branch. That branch still calls ovpn_peer_put(peer). At this point, however, peer is the currently published replacement peer, not the peer associated with the socket being destroyed. Dropping its reference can free it while ovpn->peer still points to it, leading to later use-after-free accesses from the peer and socket cleanup paths. KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer object. In the reproducer, the object is allocated from ovpn_peer_new() via ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU callback processing. Observed access sites include ovpn_peer_remove(), ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn(). Fix this by returning from the socket mismatch branch without putting the peer.", "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-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-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-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-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-68356", "url": "https://ubuntu.com/security/CVE-2026-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: airoha: Prevent division by zero when clock frequency is zero clk_get_rate() can return 0 when the clock provider is not properly configured or the clock is unmanaged. The driver uses wdt_freq as a divisor directly in airoha_wdt_probe() to compute max_timeout and in airoha_wdt_get_timeleft() to compute the remaining time, which results in a division by zero. Add a check for wdt_freq == 0 in probe and return -EINVAL with dev_err_probe() to prevent the division by zero and provide a diagnostic message.", "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-68358", "url": "https://ubuntu.com/security/CVE-2026-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-kraken3) 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-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-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-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-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-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-68374", "url": "https://ubuntu.com/security/CVE-2026-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: sysfs: add lock to bos_descriptors_read() Add a lock to the function bos_descriptors_read(). This function accesses udev->bos, which could be simultaneously freed in usb_reset_and_verify_device(), a function that is commonly called in drivers all over the kernel.", "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-68378", "url": "https://ubuntu.com/security/CVE-2026-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions: - A pin is registered with two or more dpll devices (dpll_A, dpll_B) - The pin has ref_sync pairs with other pins - During unregistration of dpll_A's pins, a ref_sync partner pin is unregistered first, removing it from dpll_A->pin_refs - But since the partner pin is still registered with dpll_B, its dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT run and the partner stays in the pin's ref_sync_pins xarray - When the pin itself is then unregistered from dpll_A, the delete notification calls dpll_msg_add_pin_ref_sync() which finds the partner in ref_sync_pins, passes dpll_pin_available() (partner is still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A, partner) returns NULL because partner was already removed from dpll_A->pin_refs - The NULL priv pointer is passed to the driver's ref_sync_get callback, which dereferences it BUG: kernel NULL pointer dereference, address: 0000000000000034 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x] Call Trace: dpll_msg_add_pin_ref_sync+0xb8/0x200 dpll_cmd_pin_get_one+0x3b6/0x4b0 dpll_pin_event_send+0x72/0x140 __dpll_pin_unregister+0x5a/0x2b0 dpll_pin_unregister+0x49/0x70 Fix this by skipping ref_sync pins whose priv pointer cannot be resolved for the current dpll device.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68379", "url": "https://ubuntu.com/security/CVE-2026-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix TIME_WAIT socket reference leak on PSP policy failure Release the TIME_WAIT socket reference and jump to discard_it upon PSP policy failure in both IPv4 and IPv6 receive paths. This prevents a memory leak of tcp_tw_bucket structures.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68380", "url": "https://ubuntu.com/security/CVE-2026-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix use-after-free of mm_struct in job scheduler amdxdna_cmd_submit() stores current->mm in job->mm without holding any reference. aie2_sched_job_run() later access job->mm from the DRM scheduler worker thread. With only a raw pointer and no structural reference, the mm_struct can be freed before the scheduler runs the job. Fix this by calling mmgrab() to hold a structural mm_count reference for the lifetime of the job, paired with mmdrop() in every cleanup path.", "cve_priority": "high", "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-68384", "url": "https://ubuntu.com/security/CVE-2026-68384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits. - Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it. While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one. (cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68385", "url": "https://ubuntu.com/security/CVE-2026-68385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/checksum: Fix csum_partial() without vector facility Currently csum_partial() calls csum_copy() with copy=false and dst=NULL. On machines without the vector facility, csum_copy() falls back to cksm(dst, ...), causing the checksum to be calculated from address zero instead of the source buffer. The VX implementation already checksums data loaded from src. Make the fallback do the same by passing src to cksm().", "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-68387", "url": "https://ubuntu.com/security/CVE-2026-68387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: add locking for raw flags bitfield With commit 890e5198a6e5 (\"can: raw: use bitfields to store flags in struct raw_sock\") the formerly separate integer values have been integrated into a single bitfield. This led to a read-modify-write operation when changing a flag in raw_setsockopt() which now needs a locking to prevent concurrent access. Instead of adding a lock/unlock hell in each of the flag manipulations this patch introduces a wrapper for a new raw_setsockopt_locked() function analogue to the isotp_setsockopt[_locked]() approach in net/can/isotp.c [mkl: use Closes tag instead of Link]", "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-68393", "url": "https://ubuntu.com/security/CVE-2026-68393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: extend conn_hash lookup critical sections Using RCU-protected pointers outside the critical sections without refcount is incorrect and may result to UAF. Extend critical section to cover both hci_conn_hash lookup and use of the returned conn. Add surrounding rcu_read_lock() also when return value is not used, in preparation for RCU lockdep requirement to hci_lookup_le_connect(). This avoids concurrent deletion of the conn before we are done dereferencing it. Also, make sure to hold hdev->lock when accessing hdev->accept_list.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68394", "url": "https://ubuntu.com/security/CVE-2026-68394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update MGMT_OP_LOAD_CONN_PARAM queues conn_update_sync() when a single parameter update changes an existing LE central connection. The queued work currently stores a borrowed hci_conn_params entry from hdev->le_conn_params. A later LOAD_CONN_PARAM request can clear disabled parameters and free that entry before hci_cmd_sync_work() runs the queued callback. Do not keep the borrowed hci_conn_params pointer in queued work. Queue the hci_conn instead and hold a reference until the queued callback completes. When the work runs, revalidate that the connection is still present, look up the current hci_conn_params entry, and cancel the update if userspace removed that entry while the work was pending. Copy the interval values from the current params entry under hdev->lock, then drop the lock and keep using hci_le_conn_update_sync() to issue the update. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in conn_update_sync+0x2a/0xf0 [bluetooth] Read of size 1 at addr ffff88810c697126 by task kworker/u17:0/377 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 kasan_report+0xe0/0x110 conn_update_sync+0x2a/0xf0 [bluetooth] hci_cmd_sync_work+0x187/0x210 [bluetooth] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 Allocated by task 466: hci_conn_params_add+0xa6/0x240 [bluetooth] load_conn_param+0x4e1/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] Freed by task 474: kfree+0x313/0x590 hci_conn_params_clear_disabled+0x9b/0xc0 [bluetooth] load_conn_param+0x4bf/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth]", "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-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-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-68400", "url": "https://ubuntu.com/security/CVE-2026-68400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint memory access array and to comply with the FF-A spec instead of defaulting to `sizeof(struct ffa_mem_region)`. This requires moving `ffa_mem_region_additional_setup()` earlier in the setup flow. Also, add sanity checks to ensure the calculated descriptor offsets do not exceed `max_fragsize`.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68401", "url": "https://ubuntu.com/security/CVE-2026-68401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() Sashiko (locally) reports multiple out-of-bound issues in ffa_setup_and_transmit: 1) Writing ep_mem_access->reserved can write out of bounds for FFA versions < 1.2 as ffa_emad_size_get() returns 16 bytes in that case while reserved has an offset of 24. Instead of zeroing fields, memset the struct to zero first based on the FFA version. 2) Make sure there is enough size to write constituents. While at it, convert the only sizeof() in the driver that uses a type instead of variable.", "cve_priority": "high", "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-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-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-68409", "url": "https://ubuntu.com/security/CVE-2026-68409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: defer link RX stats percpu free to RCU sta_remove_link() frees a removed MLO link's RX stats percpu buffer right away, but defers only the link container to RCU: \tsta_info_free_link(&alloc->info); \tkfree_rcu(alloc, rcu_head); The RX fast path reads link_sta under rcu_read_lock and writes the percpu stats. A reader that resolved link_sta before the removal keeps the pointer. The container stays alive from the kfree_rcu, so the read still works. But the percpu block it points to is already freed. This needs uses_rss. That is when pcpu_rx_stats exists. The full STA teardown frees the deflink stats only after synchronize_net(). The link removal path had no such barrier. The race is hard to win in practice, but the free should still wait for RCU. Free the link together with its data from a single RCU callback, so the percpu block is reclaimed only after readers drain.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20: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-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-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-68412", "url": "https://ubuntu.com/security/CVE-2026-68412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan() If the test against IEEE80211_MAX_SSID_LEN fails, then 'creq' leaks. Use the existing error handling path to fix it.", "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-64566", "url": "https://ubuntu.com/security/CVE-2026-64566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags() When iptfs_skb_add_frags() copies frag references from the source frag walk into a new SKB, it increments the page reference count via __skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the destination SKB's skb_shinfo->flags. If the source SKB carries shared frags (e.g. from a page-pool backed receive path), the new inner SKB will appear to ESP as having privately owned frags. A subsequent esp_input() call for a nested transport-mode SA then takes the no-COW fast path and decrypts in place, writing over pages that are still referenced by the outer IPTFS SKB. This causes kernel-visible memory corruption and can trigger a panic. All other frag-transfer helpers in the kernel (skb_try_coalesce, skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this convention by setting the flag inside the loop immediately after __skb_frag_ref() and nr_frags++, so every exit path that attaches a frag unconditionally propagates SKBFL_SHARED_FRAG.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68415", "url": "https://ubuntu.com/security/CVE-2026-68415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear mode callbacks after failed mode setup xfrm_state_gc_task can run long after a failed IPTFS state setup. In the reproduced case, __xfrm_init_state() cached x->mode_cbs, IPTFS setup returned -ENOMEM before publishing mode_data, and the temporary module reference from xfrm_get_mode_cbs() was dropped immediately. The dead state then kept x->mode_cbs until deferred GC ran after xfrm_iptfs had been unloaded. Clear x->mode_cbs when mode init or clone fails before publishing mode_data. Those states never installed mode-specific state or the long-term IPTFS module pin, so deferred GC has nothing mode-specific to destroy and must not retain a callback table pointer past the temporary lookup reference. The buggy scenario involves two paths, with each column showing the order within that path: failed setup path: 1. cache x->mode_cbs 2. mode setup fails before mode_data 3. drop the temporary module ref 4. dead state keeps x->mode_cbs cached GC/unload path: 1. xfrm_state_put() queues GC work 2. xfrm_iptfs unloads later 3. xfrm_state_gc_task runs 4. GC dereferences stale x->mode_cbs This also covers the failed clone path where clone_state() returns before publishing mode_data. Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y failslab_stacktrace_filter matched xfrm_iptfs frames ack_error=-12 FAULT_INJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrm_state_gc_task RIP: xfrm_state_gc_task+0x142/0x650 Modules linked in: esp4_offload xfrm_user [last unloaded: xfrm_iptfs] Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68418", "url": "https://ubuntu.com/security/CVE-2026-68418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent user-triggered null deref on QP create Previously, the user QP creation path would only attempt to populate iwqp->iwpbl if the user-provided req.user_wqe_bufs field was non-zero. The problem is that iwqp->iwpbl is unconditionally dereferenced later on in irdma_setup_virt_qp. While there was a check for iwqp->iwpbl != NULL, this check would only occur if req.user_wqe_bufs was non-zero. The end result is that a user could send a zero user_wqe_bufs value and trigger a null ptr deref. Fix this by unconditionally calling irdma_get_pbl and bailing if it fails, similar to the CQ and SRQ paths.", "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-68420", "url": "https://ubuntu.com/security/CVE-2026-68420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: reject optional IPTFS templates in outbound policies syzbot reported a stack-out-of-bounds read in xfrm_state_find() which flows from xfrm_tmpl_resolve_one(). Commit 3d776e31c841 (\"xfrm: Reject optional tunnel/BEET mode templates in outbound policies\") disallowed optional tunnel and BEET in outbound policies to prevent this. Later when IPTFS added, it was not covered by that fix and can still trigger the out-of-bounds read; Extend the check to disallow optional IPTFS in outbound policies as well. IPTFS should be identical to tunnel mode. IN and FWD policies are not affected: xfrm_tmpl_resolve_one() is only reachable via the outbound path. Reproducer, before: ip link add dummy0 type dummy ip link set dummy0 up ip addr add 10.1.1.1/24 dev dummy0 ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 mode transport ping -W 1 -c 1 10.1.1.2 PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data. [ 64.168420] ================================================================== [ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844 [ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full) [ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 64.169977] Call Trace: [ 64.169977] [ 64.169977] dump_stack_lvl+0x47/0x70 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] print_report+0x152/0x4b0 [ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0 [ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20 [ 64.169977] ? __virt_addr_valid+0x21b/0x230 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] kasan_report+0xa8/0xd0 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm_dst_hash+0x24/0xc0 [ 64.169977] xfrm_state_find+0xa2d/0x2f90 [ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570 [ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10 [ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 64.169977] ? kernel_text_address+0x5b/0x80 [ 64.169977] ? __kernel_text_address+0xe/0x30 [ 64.169977] ? unwind_get_return_address+0x5e/0x90 [ 64.169977] ? arch_stack_walk+0x8c/0xe0 [ 64.169977] xfrm_tmpl_resolve+0x130/0x200 [ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10 [ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110 [ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10 [ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310 [ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80 [ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10 [ 64.169977] ? ip_route_output_key_hash+0xc6/0x110 [ 64.169977] ? kasan_save_track+0x10/0x30 [ 64.169977] xfrm_lookup_route+0x18/0xe0 [ 64.169977] ip4_datagram_release_cb+0x4c9/0x530 [ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10 [ 64.169977] ? do_raw_spin_lock+0x71/0xc0 [ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 64.169977] release_sock+0xb0/0x170 [ 64.169977] udp_connect+0x43/0x50 [ 64.169977] __sys_connect+0xa6/0x100 [ 64.169977] ? alloc_fd+0x2e9/0x300 [ 64.169977] ? __pfx___sys_connect+0x10/0x10 [ 64.169977] ? preempt_latency ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68421", "url": "https://ubuntu.com/security/CVE-2026-68421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx() put_prev_task_scx() warns when a runnable task drops to a lower sched_class without SCX_OPS_ENQ_LAST, on the assumption that balance_one() would have kept it running. Core scheduling breaks that: a forced-idle SMT sibling reschedules through the core_pick fast path in pick_next_task(), which skips pick_task_scx() and thus balance_one(), so a runnable task can drop to idle with ENQ_LAST unset. Gate the warning on sched_cpu_cookie_match(): a cookie mismatch means core scheduling forced the idle, while a match (or core scheduling off) still catches a genuine missing-ENQ_LAST drop.", "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-68426", "url": "https://ubuntu.com/security/CVE-2026-68426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix stale skb->prev after async crypto steals a GSO segment skb_gso_segment() leaves the segment list head with ->prev pointing at the last segment, an invariant validate_xmit_skb_list() relies on when it sets its tail pointer (tail = skb->prev). When validate_xmit_xfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validate_xmit_skb_list() later does tail->next = skb, writing through that stale pointer -- a use-after-free. Repoint skb->prev at the last retained segment before returning.", "cve_priority": "critical", "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-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-2023-20585", "url": "https://ubuntu.com/security/CVE-2023-20585", "cve_description": "Insufficient checks of the RMP on host buffer access in IOMMU may allow an attacker with privileges and a compromised hypervisor to trigger an out of bounds condition without RMP checks, resulting in a potential loss of confidential guest integrity.", "cve_priority": "low", "cve_public_date": "2026-04-16 19:16:00 UTC" }, { "cve": "CVE-2026-68364", "url": "https://ubuntu.com/security/CVE-2026-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix ISM dc_lock deadlock during suspend [Why] System hang observed during suspend/resume while video is playing. amdgpu_dm_ism_disable() is called under dc_lock and waits for ISM delayed work via disable_delayed_work_sync(). The work handlers themselves take dc_lock, producing an ABBA deadlock when a worker is in flight at suspend time. [How] Split the disable path into two phases with opposite locking contracts: 1. amdgpu_dm_ism_disable() -- quiesces workers, must NOT hold dc_lock. 2. amdgpu_dm_ism_force_full_power() (new) -- drives the ISM FSM back to FULL_POWER_RUNNING, must hold dc_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72064", "url": "https://ubuntu.com/security/CVE-2026-72064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Sync page pool RX frags for CPU MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack.", "cve_priority": "medium", "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-72098", "url": "https://ubuntu.com/security/CVE-2026-72098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: fix buffer overflow in FEC calculation There's a buffer overflow in dm-verity-fec: if (neras && *neras <= v->fec->roots) \tfio->erasures[(*neras)++] = i; This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72248", "url": "https://ubuntu.com/security/CVE-2026-72248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: support IPIP tunnel with direct xmit The combination of IPIP tunnel with direct xmit, eg. bridge device, breaks because no dst_entry is provided to check the skb headroom and to set the iph->frag_off field. This leads to invalid dst usage and can trigger a crash in the tunnel transmit path. Fix this by moving dst_cache and dst_cookie out of the runtime union so that they can be shared by neighbour, xfrm, and direct tunnel flows. For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve route state in these shared fields and release it through the common dst release path. Since dst_entry is now available to the three supported xmit modes and dst_release() already deals with NULL dst, remove the xmit type check in nft_flow_dst_release(). Moreover, skip the check if the dst entry is NULL in nf_flow_dst_check() which is now the case for the direct xmit case. Based on patch from Rein Wei .", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72249", "url": "https://ubuntu.com/security/CVE-2026-72249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: use dst in this direction when pushing IPIP header When pushing the IPIP header, the route of the other direction is used to calculate the headroom, use the route in this direction. Accessing the other tuple to set the IP source and destination is fine because this tuple does not provide such information to avoid storing redundant information. However, this tuple already provides the dst for this direction, this went unnoticed because this bug affects headroom and iph->frag_off only at this stage.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72287", "url": "https://ubuntu.com/security/CVE-2026-72287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the \"normal\" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a \"late\" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72329", "url": "https://ubuntu.com/security/CVE-2026-72329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/liquidio: drop cached VF pci_dev LUT The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST. Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72355", "url": "https://ubuntu.com/security/CVE-2026-72355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix barriering when walking subrequest list Fix the barriering used when walking the subrequest list in retry as there's a possibility of seeing a subreq that's just been added by the application thread.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72412", "url": "https://ubuntu.com/security/CVE-2026-72412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/mm: Fix handling of _PAGE_UNUSED pte bit The _PAGE_UNUSED softbit should not really be lying around. Its sole purpose is to signal to try_to_unmap_one() and try_to_migrate_one() that the page can be discarded instead of being moved / swapped. KVM has no way to know why a page is being unmapped, so it sets the bit on userspace ptes corresponding to unused guest pages every time they get unmapped. KVM has no reasonable way to clear the bit once the page is in use again. While set_ptes() checks and clears the bit, other paths that set new ptes did not. This led to used pages being thrown out as if they were unused, causing guest corruption. Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in set_pte(), i.e. whenever a present pte is getting set. The check in set_ptes() is then redundant and can be removed. Also fix gmap_helper_try_set_pte_unused() to only set the bit if the pte is present; the _PAGE_UNUSED bit is only defined for present ptes and thus should not be set for non-present ptes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72417", "url": "https://ubuntu.com/security/CVE-2026-72417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto() Add sanity check for iph->ihl field in nf_flow_ip4_tunnel_proto() before using it to compute the header size, avoiding out-of-bounds access with malformed IP headers. While at it, use iph->protocol instead of the hardcoded IPPROTO_IPIP constant when setting ctx->tun.proto and reference ctx->tun.hdr_size when updating ctx->offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72442", "url": "https://ubuntu.com/security/CVE-2026-72442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: fix and simplify IP6IP6 tunnel handling Fix nf_flow_ip6_tunnel_proto() to use pskb_may_pull() instead of skb_header_pointer() to ensure the outer IPv6 header is in the skb headroom, which is required for subsequent packet processing. Move ctx->offset update inside the IPPROTO_IPV6 conditional block since it should only be adjusted when an IP6IP6 tunnel is actually detected. Simplify the rx path by removing ipv6_skip_exthdr() and checking ip6h->nexthdr directly, as the flowtable fast path only handles simple IP6IP6 encapsulation without extension headers. Drop the tunnel encapsulation limit destination option support from the tx path to match, since the rx path no longer handles extension headers. Remove the encap_limit parameter from nf_flow_offload_ipv6_forward(), nf_flow_tunnel_ip6ip6_push() and nf_flow_tunnel_v6_push(), along with the ipv6_tel_txoption struct and related headroom/MTU adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72463", "url": "https://ubuntu.com/security/CVE-2026-72463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix dev use-after-free in xfrm async resumption xfrm async resumption hold skb->dev refcnt until after transport_finish. However, xfrm_rcv_cb may modify skb->dev to tunnel dev without taking device reference, such as vti_rcv_cb. The subsequent async resumption will decrement the tunnel device's reference count, which lead to uaf of tunnel dev and refcnt leak of orig dev as below: unregister_netdevice: waiting for vti1 to become free. Usage count = -2 Stash the original skb->dev to fix refcnt imbalance. The new skb->dev set by xfrm_rcv_cb can race with device teardown. Extend rcu protection over xfrm_rcv_cb and transport_finish to prevent races.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72477", "url": "https://ubuntu.com/security/CVE-2026-72477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: call _ntfs_bad_inode() when failing to rename It is safe to call _ntfs_bad_inode on live inodes since: commit 519b078998ce (\"fs/ntfs3: Exclude call make_bad_inode for live nodes.\") The WARN_ON was added when it wasn't safe by: commit d99208b91933 (\"fs/ntfs3: cancle set bad inode after removing name fails\") Replace the WARN_ON with a call to _ntfs_bad_inode() to prevent further operations on the inconsistent inode.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72493", "url": "https://ubuntu.com/security/CVE-2026-72493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: serialize netif_running() check in enqueue_to_backlog() Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup(). The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit). Commit e9e4dd3267d0 (\"net: do not process device backlog during unregistration\") introduced a lockless netif_running() check in enqueue_to_backlog() to prevent queuing packets to an unregistering device. However, this creates a TOCTOU race window. A lockless transmitter (like veth_xmit) can pass the check before dev_close() clears IFF_UP. If the transmitter is then delayed, flush_all_backlogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed. Fix this by moving the netif_running() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netif_running() after the flush/close completes (so it gets dropped).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72494", "url": "https://ubuntu.com/security/CVE-2026-72494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Replace waitqueue and flag with completion The driver previously used a waitqueue along with an explicit request_done flag, but without proper barriers around request_done. An earlier patch by Gui-Dong Han attempted to fix this by adding the missing memory barriers. Rather than adding the barriers, this patch replaces the waitqueue+flag with a completion, which is designed for this exact purpose.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72496", "url": "https://ubuntu.com/security/CVE-2026-72496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Proper rollback if the ioremap fails bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74269", "url": "https://ubuntu.com/security/CVE-2026-74269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt: fix head underflow on XDP head-grow The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free. The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with this commit applied causes the test to run successfully to completion. The other rx_skb_func implementations don't have this issue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74350", "url": "https://ubuntu.com/security/CVE-2026-74350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate fast symlink target during inode read ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment. A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer. Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated. This keeps malformed fast symlinks from reaching the read path. Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x19f/0x330 (?:?) kasan_report+0xe0/0x110 (?:?) kasan_check_range+0x105/0x1b0 (?:?) __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72495", "url": "https://ubuntu.com/security/CVE-2026-72495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid repeated requests to allocate WC pages Applications can request multiple WC pages for the same ucontext. As of now, only 1 WC page per ucontext is supported. Add a lock to avoid concurrent access and a check to fail repeated requests. Also, if the mmap entry insert fails for the WC, free the Doorbell page index mapped for the WC page.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72501", "url": "https://ubuntu.com/security/CVE-2026-72501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Initialize dpi variable to zero dpi is initialized only for BNXT_RE_ALLOC_WC_PAGE, but copied for all the cases. So initialize the dpi to 0.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72278", "url": "https://ubuntu.com/security/CVE-2026-72278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Re-translate VNCR before injecting abort KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor updates and MMU faults.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68083", "url": "https://ubuntu.com/security/CVE-2026-68083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix path resolution in ksmbd_vfs_kern_path_create The SMB2 open lookup is rooted at the share with LOOKUP_BENEATH, but the create/mkdir/hardlink sink is not: ksmbd_vfs_kern_path_create() builds an absolute path with convert_to_unix_name() and resolves it from AT_FDCWD via start_creating_path(), so a \"..\" component is walked from the real filesystem root and escapes the export. An authenticated client races a missing path component so the rooted open lookup returns -ENOENT (taking the create branch) while the same component is present (a directory) when the create walk runs; the create then resolves \"..\" out of the share. Root the create walk at the share like the lookup and rename paths already are: resolve the parent with vfs_path_parent_lookup(..., LOOKUP_BENEATH, &share_conf->vfs_path) and create the final component with start_creating_noperm(). convert_to_unix_name() then has no callers and is removed.", "cve_priority": "high", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-68457", "url": "https://ubuntu.com/security/CVE-2026-68457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use opener credentials for FSCTL mutations SET_SPARSE, SET_ZERO_DATA and SET_COMPRESSION operate on an open SMB handle but call VFS xattr, fallocate or fileattr helpers with the current ksmbd worker credentials. Those helpers can revalidate inode permissions, ownership and LSM policy independently of the SMB handle access mask. Run each operation with the credentials captured in the target file when the handle was opened. Keep credential handling local to these single-file FSCTLs rather than applying session credentials to the complete IOCTL handler, which also contains handle-less and multi-handle operations.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72041", "url": "https://ubuntu.com/security/CVE-2026-72041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: use sk_msg_free_partial to fix partial send sk_msg_free_partial() ensures consistency of the skmsg at every iteration, without having to manually handle uncharges and offsets. This simplifies the code, and fixes some bugs in skmsg accounting when we don't send the full contents.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72046", "url": "https://ubuntu.com/security/CVE-2026-72046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing.", "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-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21: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-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72137", "url": "https://ubuntu.com/security/CVE-2026-72137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: nat_keepalive: avoid double free on send error nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6 send helper reports an error. That cleanup is only correct before the skb is handed to the output path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the networking stack may already have consumed the skb before returning an error, so freeing it again is unsafe. Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4() and nat_keepalive_send_ipv6(), where the caller still owns the skb, and keep nat_keepalive_send() responsible only for family dispatch and the unsupported-family cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72139", "url": "https://ubuntu.com/security/CVE-2026-72139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: defer md5sig_info kfree past RCU grace period in tcp_connect The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: \tif (needs_md5) { \t\ttcp_ao_destroy_sock(sk, false); \t} else if (needs_ao) { \t\ttcp_clear_md5_list(sk); \t\tkfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); \t} Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with tcp-diag]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72191", "url": "https://ubuntu.com/security/CVE-2026-72191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: validate split-point offset in indx_insert_into_buffer indx_insert_into_buffer() computes used = used1 - to_copy - sp_size; memmove(de_t, Add2Ptr(sp, sp_size), used - le32_to_cpu(hdr1->de_off)); where sp and sp_size come from hdr_find_split(). hdr_find_split() walks entries by le16_to_cpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFS_DE). index_hdr_check(), the on-load gatekeeper, only validates header-level fields (used, total, de_off) and does not walk per-entry sizes. A crafted NTFS image whose leaf INDEX_HDR reports used == total but contains one interior NTFS_DE with size = 0xFFF0 therefore passes validation, descends to indx_insert_into_buffer() through the ntfs_create() -> indx_insert_entry() path, and makes hdr_find_split() return an sp whose sp_size (0xFFF0) greatly exceeds the remaining bytes in the buffer. The u32 subtraction underflows and the memmove count becomes a near-4-GiB value, producing an out-of-bounds kernel write that corrupts adjacent allocations and panics the kernel. Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a single 'touch' inside the mounted directory; crash site resolves to fs/ntfs3/index.c at the memmove. Trigger requires only local mount of an attacker-supplied filesystem image (USB, loopback, or removable media auto-mount). Reject the split whenever the chosen sp plus its declared size already extends past hdr1->used. This is the minimal fix; it preserves the existing hdr_find_split() contract and relies on the same out: cleanup path as the pre-existing error returns. A prior OOB read in the very same indx_insert_into_buffer() memmove was fixed in commit b8c44949044e (\"fs/ntfs3: Fix OOB read in indx_insert_into_buffer\") by tightening hdr_find_e(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdr_find_split(), not hdr_find_e(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72217", "url": "https://ubuntu.com/security/CVE-2026-72217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing xdr_buf_to_bvec() writes a bio_vec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it. rq_bvec, the array passed by nfsd_vfs_write(), is allocated to exactly rq_maxpages entries with no slack. The OOB store can land in adjacent slab memory; the bv_len and bv_offset fields written there are derived from client-supplied RPC payload sizes. Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72220", "url": "https://ubuntu.com/security/CVE-2026-72220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp->rq_procinfo->pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72221", "url": "https://ubuntu.com/security/CVE-2026-72221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: wait for in-flight TLS handshake callback when cancel loses race When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed. The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result. If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue. If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed. Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed to fire because handshake_complete() invokes svc_tcp_handshake_done() unconditionally once it has set HANDSHAKE_F_REQ_COMPLETED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72222", "url": "https://ubuntu.com/security/CVE-2026-72222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: pin svc_xprt across the asynchronous TLS handshake callback svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of(). Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done. The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry. Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all(). [cel: rewrote commit message to describe the actual change]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72277", "url": "https://ubuntu.com/security/CVE-2026-72277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the simpler thing for now and just reject everything that isn't memory.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72279", "url": "https://ubuntu.com/security/CVE-2026-72279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR KVM currently maps the L1 VNCR into the host stage-1 by relying entirely on the permissions of the guest stage-1. At the same time, it is entirely possible that the backing PFN is read-only (e.g. RO memslot), meaning that the L1 VNCR should use at most a read-only mapping. Cache the writability of the PFN in the VNCR TLB and use it to constrain the resulting fixmap permissions. Promote VNCR permission faults to an SEA in the case where the guest attempts to write to a read-only endpoint. Conveniently, this also plugs a page leak found by Sashiko [*] resulting from the early return for a read-only PFN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72288", "url": "https://ubuntu.com/security/CVE-2026-72288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling Hyunwoo Kim reports some really bad races should the following situation occur: - LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C If the last two race nicely enough, vgic_prune_ap_list() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows. The fix is two-fold: - Before dropping the irq and ap_list locks, take a reference on the irq - Do not try to handle migration of the pending bit: there is no expectation that this state is retained, as per the architecture With that, we're sure that the interrupt is still around, and we safely remove it from the AP list as it has no target at this stage (unless another interrupt fires, but that's another story).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "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-72317", "url": "https://ubuntu.com/security/CVE-2026-72317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: pin upper rpc_clnt across the TLS connect_worker The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt. The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported. Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one. The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72318", "url": "https://ubuntu.com/security/CVE-2026-72318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate DFS referral string offsets parse_dfs_referrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server. Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative max_len is then passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds. Validate each string offset before deriving the string pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72320", "url": "https://ubuntu.com/security/CVE-2026-72320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_lookup: fix catchall element handling with inverted lookups nft_lookup_eval() decides whether a lookup matched (`found`) from the direct set lookup and priv->invert before falling back to the catchall element used by interval sets (e.g. nft_set_rbtree) for the open-ended default range. Since `found` is never recomputed after `ext` is replaced by the catchall lookup, inverted lookups (NFT_LOOKUP_F_INV, \"!= @set\") can wrongly match or wrongly skip the catchall element, producing the wrong verdict. Fold the catchall lookup into `ext` before computing `found`, matching the order already used by nft_objref_map_eval().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72366", "url": "https://ubuntu.com/security/CVE-2026-72366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_create_write_req() to handle async cache object creation netfs_create_write_req() will skip caching if the fscache cookie is disabled, but this is a problem because async cache object creation might not have got far enough yet that has been enabled - thereby causing the call to fscache_begin_write_operation() to be skipped. Fix this by removing the checks on the cookie and delegating this to fscache_begin_write_operation().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72381", "url": "https://ubuntu.com/security/CVE-2026-72381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of fp->owner.name in durable handle owner check Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d (\"ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd\") made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized. BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8 Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72393", "url": "https://ubuntu.com/security/CVE-2026-72393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: don't cache shinfo across skb realloc fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb including the shared info. We can't use the pointer calculated before the call. BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0 Read of size 4 at addr ff110000262edd98 by task swapper/5/0 Call Trace: fbnic_tx_lso.isra.0+0x668/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 Allocated by task 8653: __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xcc/0x6c0 sock_alloc_send_pskb+0x327/0x3f0 __ip_append_data+0x188b/0x47a0 ip_make_skb+0x24a/0x300 udp_sendmsg+0x14d2/0x21e0 Freed by task 0: kfree+0x123/0x5a0 pskb_expand_head+0x36c/0xfa0 fbnic_tx_lso.isra.0+0x500/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 sch_direct_xmit+0x25b/0x1100 The buggy address belongs to the object at ff110000262edc40 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 344 bytes inside of freed 640-byte region [ff110000262edc40, ff110000262ede", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72398", "url": "https://ubuntu.com/security/CVE-2026-72398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: add INIT verification after cookie unpacking In SCTP handshake, the INIT chunk is initially processed by the server and embedded into the cookie carried in INIT-ACK. The client then returns this cookie via COOKIE-ECHO, where the server unpacks it and reconstructs the original INIT chunk. When cookie authentication is enabled, the cookie contents are protected against tampering, so reusing the unpacked INIT without re-verification is safe. However, when cookie authentication is disabled, the reconstructed INIT can no longer be trusted. In this case, the INIT must be explicitly validated after unpacking to avoid processing potentially tampered data. Add sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO processing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook()) when cookie_auth_enable is disabled. On failure, the new association is freed and the packet is discarded. Also tighten cookie validation in sctp_unpack_cookie() by verifying the embedded chunk type is SCTP_CID_INIT before treating it as an INIT chunk. Finally, update sctp_verify_init() to validate parameter bounds using the actual embedded INIT length instead of chunk->chunk_end, since the INIT stored in COOKIE-ECHO may not span the entire chunk buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72399", "url": "https://ubuntu.com/security/CVE-2026-72399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: check the number of BDs needed for xdp_frame The size of xdp_redirect_arr array is ENETC_MAX_SKB_FRAGS. However, the number of fragments contained in xdp_frame may be greater than or equal to ENETC_MAX_SKB_FRAGS, which will cause the access to xdp_redirect_arr to be out of bounds.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72429", "url": "https://ubuntu.com/security/CVE-2026-72429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix type confusion of dst_entry IOAM uses a dummy dst_entry(null_dst) to mark that the destination should not be changed after the transformation. This dst is stored in the IOAM lwt state and may be passed to dst_cache_set_ip6(). However, the IPv6 dst cache path eventually calls rt6_get_cookie(), which treats the dst_entry as part of a struct rt6_info. Since the null_dst was embedded directly as a struct dst_entry in struct ioam6_lwt, this resulted in an invalid cast and rt6_get_cookie() reading fields from the wrong object. In practice, the wrong cookie is not used while dst->obsolete is zero, but rt6_get_cookie() may also access per-cpu value when rt->sernum is zero. In this case, rt->sernum aliases ioam6_lwt::cache::reset_ts, which can become zero, making this a potential invalid pointer access. Fix this by embedding a full struct rt6_info for the dummy IPv6 route and passing its dst member to the dst APIs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72436", "url": "https://ubuntu.com/security/CVE-2026-72436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash types Sashiko pointed out that there are a few lockless RCU readers using test_bit() which is a relaxed atomic operation and provides no memory barrier guarantees. Use test_bit_acquire() instead where the operation may run parallel with add/del/gc, i.e. is not one from the next cases - protected by region lock - in a set destroy phase - in a new/temporary set creation phase", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72451", "url": "https://ubuntu.com/security/CVE-2026-72451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix xfrm state cache insertion race The xfrm input state cache insertion code checks the validity of the state before acquiring the global xfrm_state_lock. Thus it's possible for someone else to kill the state after it passed the validity check, and then the insertion will add the dead state to the cache. Fix this by moving the validity check inside the lock. This entire function is called on the input path, where BH must be off (e.g., the caller of this function xfrm_input acquires its spinlocks without disabling BH). So there is no need to disable BH here or take the RCU read lock. Remove both and replace them with an assertion that trips if BH is accidentally enabled on some future calling path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72472", "url": "https://ubuntu.com/security/CVE-2026-72472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: use nfsi->rwsem to protect traversal of the file lock list Lingfeng identified a bug and suggested two solutions, but both appear to have issues. Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case. Furthermore, after commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk. Regarding the bug fixed by commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), it has been resolved after commit 0460253913e5 (\"NFSv4: nfs4_do_open() is incorrectly triggering state recovery\") because all slots are drained before calling nfs4_do_reclaim, which prevents concurrent stateid changes along this path. Also, nfs_delegation_claim_locks does not cause this concurrency either since when _nfs4_proc_setlk is called with NFS_DELEGATED_STATE, no RPC is sent, so nfs4_lock_done is not called. Therefore, nfs4_lock_delegation_recall from nfs_delegation_claim_locks is the first time the stateid is set.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72473", "url": "https://ubuntu.com/security/CVE-2026-72473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decouple req recycling from RPC completion rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer. Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off. The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry. Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied. Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected. Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released. The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74310", "url": "https://ubuntu.com/security/CVE-2026-74310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/net: complete zerocopy ubufs only once vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74345", "url": "https://ubuntu.com/security/CVE-2026-74345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix endpoint/socket association handling Disassociating a socket from an endpoint via siw_socket_disassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within. This fixes a: BUG: KASAN: slab-use-after-free in siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1053 drivers/infiniband/sw/siw/siw_cm.c:1075) which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74361", "url": "https://ubuntu.com/security/CVE-2026-74361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: fix FDP fdpcidx bounds check The fdpcidx bounds check sets n = NUMFDPC + 1 but used > instead of >=, incorrectly accepting fdp_idx when it equals n (i.e. NUMFDPC + 1).", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74401", "url": "https://ubuntu.com/security/CVE-2026-74401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix add msg handle in send_queue ordered In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as \"before(mh->seq, seq)\" will stop to check for older sequence numbers that are ordered in the tail of \"node->send_queue\". The side effects of not having it correct ordered regarding \"before(mh->seq, seq)\" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74406", "url": "https://ubuntu.com/security/CVE-2026-74406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74428", "url": "https://ubuntu.com/security/CVE-2026-74428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix double unlock in rxrpc_recvmsg() Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74433", "url": "https://ubuntu.com/security/CVE-2026-74433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix UAF in rxgk_issue_challenge() Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74434", "url": "https://ubuntu.com/security/CVE-2026-74434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Don't move a peeked OOB message onto the pending queue rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so only unlink it from recvmsg_oobq and then move it onto pending_oobq or free it when the message is actually consumed.", "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-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-74439", "url": "https://ubuntu.com/security/CVE-2026-74439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clear Present bit before tearing down scalable-mode context entry device_pasid_table_teardown() zeroes the 128-bit scalable-mode context entry with context_clear_entry() while the Present bit is still set. This creates a window where the hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behavior or spurious faults. The context-cache invalidation is issued only after the entry has been zeroed, and intel_pasid_free_table() then frees the PASID directory pages, so the IOMMU can keep walking a stale Present=1 entry that points at freed memory. While x86 provides strong write ordering, the compiler may reorder the two 64-bit writes to the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Commit c1e4f1dccbe9d (\"iommu/vt-d: Clear Present bit before tearing down context entry\") fixed this exact pattern in domain_context_clear_one() and the copied-context path, but device_pasid_table_teardown() was not converted. Align it with the \"Guidance to Software for Invalidations\" in the VT-d spec, Section 6.5.3.3, using the same ownership handshake as the sibling fix: clear only the Present bit, flush it to the IOMMU, perform the context-cache invalidation, and only then zero the rest of the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2165483, 2165484, 2165407, 2166547, 2166443, 2166356, 2165872, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165407, 2165040, 2161748, 2163508, 2163214, 2162904, 2162045, 2164967, 2160082, 2164504, 2156316, 2164716, 2164516, 2163375, 2162803, 2163062, 2132119, 2163293, 2160200, 2158858, 2162704, 2162695, 2164666, 2164666, 2163121 ], "changes": [ { "cves": [ { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-68105", "url": "https://ubuntu.com/security/CVE-2026-68105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix kernel panic during driver load failure Avoid kernel panic if MES init fails during driver load. The KIQ ring is falsely marked as ready as ASICs that use MES, KIQ is owned by MES. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] Call Trace: gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280 __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53 (cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68109", "url": "https://ubuntu.com/security/CVE-2026-68109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68114", "url": "https://ubuntu.com/security/CVE-2026-68114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit e4d99e04b2e9b13b97d3b17804c735f62689db23)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68431", "url": "https://ubuntu.com/security/CVE-2026-68431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate minimum PDU size for transform requests The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68138", "url": "https://ubuntu.com/security/CVE-2026-68138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: serialize qdisc_rtab_list against concurrent get/put qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68082", "url": "https://ubuntu.com/security/CVE-2026-68082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix two unsafe bare decodes in decode_lockers() decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-08 10:16:00 UTC" }, { "cve": "CVE-2026-68159", "url": "https://ubuntu.com/security/CVE-2026-68159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68163", "url": "https://ubuntu.com/security/CVE-2026-68163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_vma_mapped: fix device-private PMD handling Commit 65edfda6f3f2 (\"mm/rmap: extend rmap and migration support device-private entries\") introduced the concept of device-private PMD entries, but did not correctly update the rmap walk code to account for them. As a result, when page_vma_mapped_walk() encounters device-private PMD entries, it takes no action other than to acquire the PMD lock and exit. However this is highly problematic for two reasons - firstly, device private entries possess a PFN so check_pmd() needs to be called to ensure an overlapping PFN range. Secondly, and more importantly, if PVMW_MIGRATION is set the caller assumes the returned entry is a migration entry, resulting in memory corruption when the caller tries to interpret the device private entry as such. In addition, commit 146287290023 (\"mm/huge_memory: implement device-private THP splitting\") allowed device private PMDs to be split like THP mappings, but again did not update this code path. As a result, we might race a PMD split prior to acquiring the PMD lock. This patch addresses all of these issues by invoking check_pmd(), ensuring PMVW_MIGRATION is not set and checks whether a split raced us we do for PMD THP and migration entries. Instead of checking for a subset of the cases after taking the pmd_lock(), put device-private along with pmd_trans_huge() and pmd_is_migration_entry(). Also remove thp_migration_supported() as it is already guarded by pmd_is_migration_entry(). [akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68166", "url": "https://ubuntu.com/security/CVE-2026-68166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: prevent registration of special VMAs Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68170", "url": "https://ubuntu.com/security/CVE-2026-68170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix stale skb->sk reference on subflow close The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68177", "url": "https://ubuntu.com/security/CVE-2026-68177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Delay module ref count for \"enable_event\" trigger Triggers are now delayed from freeing, but can still be triggered until after the RCU grace period has ended. The freeing of the enable_event data is put into the private_data_free() callback, but the put of the module refcount is done immediately. It is possible that if a module is removed that has an event that would enable (or disable) it is still active, it can read the data of the module after it is removed causing a use-after-free bug. Move the trace_event_put_ref() that releases the module into the delayed callback so that the module can not be removed until any reference to its events are finished.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68191", "url": "https://ubuntu.com/security/CVE-2026-68191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix NULL pointer dereference in rhash table destroy When unbinding the ath12k driver, kernel NULL pointer dereferences occur in irq_work_sync() called from rhashtable_destroy(). Two hash tables are affected: 1. ath12k_link_sta hash table in ath12k_base 2. ath12k_dp_link_peer hash table in ath12k_dp The issue happens because the destroy functions are called unconditionally in cleanup paths, but the hash tables are only initialized late in their respective init functions. If the device was never fully started or if the init functions failed before initializing the hash tables, the pointers will be NULL. The issues are always reproducible from a VM because the MSI addressing initialization is failing. Call trace for ath12k_link_sta_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_link_sta_rhash_tbl_destroy+0x19/0x40 [ath12k] ath12k_core_stop+0xe/0x80 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Call trace for ath12k_dp_link_peer_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_dp_link_peer_rhash_tbl_destroy+0x29/0x50 [ath12k] ath12k_dp_cmn_device_deinit+0x21/0x140 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Fix this by adding NULL checks before calling rhashtable_destroy() in both destroy functions. The NULL check approach was chosen because the rhashtable pointer serves as the initialization state indicator. The init can fail at various points, leaving some components uninitialized. Checking the pointer directly is simpler than adding separate state flags that would need synchronization.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64586", "url": "https://ubuntu.com/security/CVE-2026-64586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: drain bus_reset work on device removal brcmf_fw_crashed() and the debugfs \"reset\" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs \"reset\" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. 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-68208", "url": "https://ubuntu.com/security/CVE-2026-68208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: Fix the error code of devm_kzalloc() in vip_probe_slice() In vip_probe_slice(), the error check for devm_kzalloc() incorrectly uses PTR_ERR_OR_ZERO() which returns 0 for NULL pointer. Return -ENOMEM for devm_kzalloc() failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68224", "url": "https://ubuntu.com/security/CVE-2026-68224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mali-c55: Fix possible ERR_PTR in enable_streams The media_pad_remote_pad_unique() function returns either a valid pointer or an ERR_PTR() on failure (-ENOTUNIQ if multiple links are enabled, -ENOLINK if no connected pad is found). The return value was assigned directly to isp->remote_src and dereferenced in the next line without checking for errors, which could lead to an ERR_PTR dereference. Add proper error checking with IS_ERR() before dereferencing the pointer. Also set isp->remote_src to NULL on error to maintain consistency with other error paths in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68237", "url": "https://ubuntu.com/security/CVE-2026-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: fix indefinite fence wait during GPU reset pre_reset only force-completes fences of MAPPED queues. A queue in any other state (e.g. mid-eviction) keeps its last_fence pending; after a GPU reset that fence never signals, so the eviction/suspend worker and process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and wedge the machine: INFO: task kworker/6:28 blocked for more than 120 seconds. Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu] Call Trace: dma_fence_wait_timeout+0x7e/0x130 amdgpu_userq_evict+0x67/0x140 [amdgpu] amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu] process_scheduled_works+0xa6/0x420 Force-complete every queue's fence regardless of state. The unmap and mark-hung step stays gated on MAPPED, since unmapping a queue that is not mapped is invalid. (cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68240", "url": "https://ubuntu.com/security/CVE-2026-68240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: publish dpagemap early to avoid device mapping leak on error drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68242", "url": "https://ubuntu.com/security/CVE-2026-68242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix NULL deref on sched_engine alloc failure Avoid using intel_context_put() before intel_context_init() in execlists_create_virtual() as the kref_put() inside would lead to NULL deref on the IOCTL path when sched_engine allocation fails. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68254", "url": "https://ubuntu.com/security/CVE-2026-68254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: require valid min/max vfreq for VRR Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68436", "url": "https://ubuntu.com/security/CVE-2026-68436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use kvzalloc to allocate struct dc struct dc has grown large over time (most of it the two inlined dc_scratch_space copies) and now sits close to the page allocator's 4 MiB contiguous allocation limit. Its actual size is not fixed by the source alone, it also depends on the compiler and the .config, so it can easily cross 4 MiB, e.g. with a newer GCC or a config change. dc_create() allocates it with kzalloc(). Once struct dc exceeds 4 MiB the request is rounded up to order 11 (8 MiB), which is above MAX_PAGE_ORDER, so the page allocator warns and returns NULL. dc_create() then fails, DM init fails and amdgpu probe aborts with -EINVAL: WARNING: mm/page_alloc.c:5197 at __alloc_frozen_pages_noprof+0x2f9/0x380 dc_create+0x38/0x660 [amdgpu] amdgpu_dm_init+0x2d9/0x510 [amdgpu] dm_hw_init+0x1b/0x90 [amdgpu] amdgpu_device_init.cold+0x150d/0x1e13 [amdgpu] amdgpu_driver_load_kms+0x19/0x80 [amdgpu] amdgpu_pci_probe+0x1e2/0x4c0 [amdgpu] dc_create() then returns NULL and DM init fails, which aborts the whole GPU init and makes amdgpu probe fail with -EINVAL (\"hw_init of IP block failed -22\"), leaving the display unusable. The subsequent amdgpu_irq_put() warnings during teardown are just fallout of unwinding a half-initialized device. struct dc is a software-only bookkeeping structure that is never handed to hardware DMA and is only ever kept as an opaque pointer, so it does not require physically contiguous memory. Allocate it with kvzalloc() (and free it with kvfree()) so that the allocator can fall back to vmalloc() when a contiguous allocation of that size is not available, which also avoids the MAX_PAGE_ORDER warning entirely. v2: - Rebase to amd-staging-drm-next. (cherry picked from commit 991e0516a8072f2292681c6ae98a924ab0e32575)", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68447", "url": "https://ubuntu.com/security/CVE-2026-68447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size from hardware without bounding it to the allocated BO region. If the HW field is larger than the queue's control stack allocation, memcpy reads past the BO into adjacent GTT memory and can leak kernel data to userspace. Store the page-aligned control stack BO size in mqd_manager and clamp checkpoint copies and reported checkpoint sizes to min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound for multi-XCC v9.4.3 checkpoint layout. (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3)", "cve_priority": "high", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68264", "url": "https://ubuntu.com/security/CVE-2026-68264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: Reset current_op in xe_pt_update_ops_init() xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it. After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind. Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry. Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(). v2 (Matt): - Add details in commit message. - Add Fixes tag and Cc to stable@vger.kernel.org (cherry picked from commit 046045543e530605c441063535e7dca0075369a6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68265", "url": "https://ubuntu.com/security/CVE-2026-68265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO's tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference (cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68267", "url": "https://ubuntu.com/security/CVE-2026-68267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists Unconditionally whitelisting OA registers is a security violation. Set RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers don't get whitelisted by default after probe, gt reset, resume and engine reset. (cherry picked from commit 90511bdcfda97211c01f1d945d4ea616578d8fca)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68273", "url": "https://ubuntu.com/security/CVE-2026-68273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68274", "url": "https://ubuntu.com/security/CVE-2026-68274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix buffer overflow in steered register list allocation The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt->fuse_topo.g_dss_mask, ...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68283", "url": "https://ubuntu.com/security/CVE-2026-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free freeing trigger private data Commit 61d445af0a7c (\"tracing: Add bulk garbage collection of freeing event_trigger_data\") moved the kfree() of event_trigger_data to a kthread that runs tracepoint_synchronize_unregister() before freeing. That removed the synchronization the trigger .free callbacks used to get implicitly and inline from trigger_data_free(). event_hist_trigger_free(), event_hist_trigger_named_free() and event_enable_trigger_free() free their satellite data (hist_data, cmd_ops, enable_data) right after trigger_data_free() returns. With the synchronization now deferred to the kthread, a concurrent tracepoint handler can still reach that data through the list_del_rcu()'d trigger, causing a use-after-free. The histogram teardown must stay synchronous: remove_hist_vars() and unregister_field_var_hists() have to detach a synthetic event from the histogram before the trigger-removal write returns, otherwise a following command races in and the synthetic-event removal fails with -EBUSY, as the trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait with the correct barrier - tracepoint_synchronize_unregister(), matching the free kthread - before freeing. The enable trigger has no such synchronous requirement, and a blocking synchronize there would re-serialize the path that commit deliberately deferred. Give it an optional private_data_free() callback that the free kthread runs after its grace period, and free enable_data from there.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68286", "url": "https://ubuntu.com/security/CVE-2026-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68287", "url": "https://ubuntu.com/security/CVE-2026-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix size calculations for 64-bit attributes net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68288", "url": "https://ubuntu.com/security/CVE-2026-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68289", "url": "https://ubuntu.com/security/CVE-2026-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68291", "url": "https://ubuntu.com/security/CVE-2026-68291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix max_vport related crash on allocation error during init Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000 [ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000 [ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20 [ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000 [ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0 [ 320.417385] PKRU: 55555554 [ 320.417398] Call Trace: [ 320.417412] [ 320.417429] pci_device_remove+0x42/0xb0 [ 320.417459] device_release_driver_internal+0x1a9/0x210 [ 320.417492] driver_detach+0x4b/0x90 [ 320.417516] bus_remove_driver+0x70/0x100 [ 320.417539] pci_unregister_driver+0x2e/0xb0 [ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0 [ 320.417592] ? kmem_cache_free+0x31e/0x550 [ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190 [ 320.417644] ? do_syscall_64+0x38/0x6b0 [ 320.417665] do_syscall_64+0xc8/0x6b0 [ 320.417683] ? clear_bhb_loop+0x30/0x80 [ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 320.417727] RIP: 0033:0x7f963bb30beb", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68303", "url": "https://ubuntu.com/security/CVE-2026-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hvs/v3d: Fix null dereference in unbind The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68312", "url": "https://ubuntu.com/security/CVE-2026-68312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and cifs_close_deferred_file_under_dentry(), when a pending deferred close is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to add the file to the local processing list may fail under memory pressure. The loop breaks immediately, but the cancelled work is no longer pending (it would have called _cifsFileInfo_put()), and the cfile is never added to file_head for processing. The cifsFileInfo reference and the open server handle both leak. Fix by saving the cfile that failed allocation in a local variable, breaking as before, and calling _cifsFileInfo_put() on it after releasing the lock. Any files later in the iteration are unaffected since their deferred work is still pending and will fire normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68316", "url": "https://ubuntu.com/security/CVE-2026-68316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Fix element size accounting for cmd stream validation There are 2 issues with the element size handling in the command stream validation which result in too small of a size calculated when the element size is 16/32/64 bits. For NHWC format, the element size is simply missing from the calculation. The bitfield for the element size is different between IFM/IFM2 and OFM. IFM and IFM2 encode the precision in parameter bits 2:3, while OFM uses bits 1:2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68440", "url": "https://ubuntu.com/security/CVE-2026-68440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix heap overflow when reading module EEPROM txgbe_read_eeprom_hostif() always copies round_up(length, 4) bytes into the caller buffer, which ethtool allocates with exactly 'length' bytes. A non-4-aligned length therefore causes an out-of-bounds write. Copy only the remaining bytes on the final dword instead.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68323", "url": "https://ubuntu.com/security/CVE-2026-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: serialize udp bearer replicast list updates tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68441", "url": "https://ubuntu.com/security/CVE-2026-68441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected. This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d (\"bpf: add bpf_redirect() helper\"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available. commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs. Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a wrapper around tcf_classify() for use by qdisc classify functions and tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT, the wrapper converts it to TC_ACT_SHOT, dropping the packet rather than letting it continue silently. Dropping is preferred over letting the packet through because the user immediately sees packet loss. Silently passing the packet through would hide the problem and leave the user wondering why their redirect is not working. The clsact fast path, tc_run() continues to call tcf_classify() directly and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by sch_handle_egress/ingress() calling skb_do_redirect() as before.", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68337", "url": "https://ubuntu.com/security/CVE-2026-68337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject redirect helpers without a bpf_net_context The bpf_redirect*() helpers and skb_do_redirect() obtain the per-task bpf_redirect_info via bpf_net_ctx_get_ri(), which dereferences the current->bpf_net_context unconditionally. That context is established on the paths that run tc BPF such as sch_handle_{ingress,egress}(), *except* for the case where {cls,act}_bpf was attached to a proper qdisc. A program running from there reaches the NULL deref in two ways: * It calls bpf_redirect() directly, which dereferences the context at the top of the helper: tc qdisc add dev eth0 root handle 1: red limit 1MB min 10KB max 20KB \\ avpkt 1000 burst 100 qevent early_drop block 10 tc filter add block 10 pref 1 bpf obj redirect.o * It simply returns TC_ACT_REDIRECT without helper call: tcf_qevent_handle() then dispatches to skb_do_redirect(), which dereferences the context Rather than extending bpf_net_context management into the qdisc path, make the redirect helpers refuse to operate when no context exists, and have tcf_qevent_handle() drop a TC_ACT_REDIRECT verdict instead of calling skb_do_redirect(). Previous behaviour was a crash, so nothing regresses by not supporting it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68345", "url": "https://ubuntu.com/security/CVE-2026-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm_mpam: guard MBWU state before adding it to garbage __destroy_component_cfg() adds each RIS mbwu_state object to the MPAM garbage list when destroying component configuration. However, mbwu_state is allocated per RIS and only for RISes with MBWU monitors. A component can therefore have comp->cfg allocated while some RISes still have ris->mbwu_state set to NULL. Passing a NULL mbwu_state to add_to_garbage() dereferences the NULL pointer inside the macro. Skip RISes that do not have an mbwu_state object before adding them to the garbage list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68347", "url": "https://ubuntu.com/security/CVE-2026-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68375", "url": "https://ubuntu.com/security/CVE-2026-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle partially initialized auxiliary devices bnxt_aux_devices_init() calls auxiliary_device_init() before all fields used by bnxt_aux_dev_release() are initialized. After auxiliary_device_init() succeeds, later errors must unwind with auxiliary_device_uninit(), which invokes the release callback. The release callback assumes that aux_priv->id, aux_priv->edev, edev->net and edev->ulp_tbl are all populated. If allocation fails after auxiliary_device_init(), the release path can otherwise dereference or clear partially initialized state. Allocate and attach the bnxt_en_dev and ULP table before calling auxiliary_device_init(), so the release callback only sees a fully initialized auxiliary private object. If auxiliary_device_init() itself fails, free those allocations directly because device_initialize() has not run and the release callback will not be invoked. 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-68382", "url": "https://ubuntu.com/security/CVE-2026-68382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Hold device ref until queue teardown completes GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock. Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending. Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work. With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. Replace the fini wait with an assertion and remove the unused fini_wq. v2: - Rebase v3: - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt) - Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt) - Drop separate deferred drm_dev_put worker. - Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini(). v4: - Replace the guc_submit_sw_fini() wait with an assertion and remove the now-unused fini_wq. (sashiko) v5: - Move destroy work to a module-lifetime Xe workqueue instead of system_dfl_wq. (Matt) - Flush the module-lifetime destroy workqueue during PCI remove to preserve the old device-remove wait semantics. v6: - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid letting it outlive the xe_device/drm_device. (Sashiko) - Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work can be queued from the reclaim path. v7: - Drop the per-device xe->destroy_wq and use the module-level destroy WQ for SVM pagemap destroy as well. (Matt) - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*() helpers because the WQ is no longer exec-queue specific. (Matt) v8: - Rebase. v9: - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM destroy_wq because it can be queued from reclaim and embeds the dev_pagemap used by devres teardown. (Sashiko) - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM from it. - Update the module-WQ kdoc to document the GuC/SVM split. v10: - Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the workqueue allocation warning. v11: - Drop the SVM pagemap destroy comment as it was revision-specific. (Thomas) v12: - Rebase. (cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68383", "url": "https://ubuntu.com/security/CVE-2026-68383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Keep scheduler timeline name alive The scheduler keeps a pointer to the timeline name, but q->name is freed with the exec queue while scheduler fences can still reference it. Store the name in struct xe_guc_exec_queue so it shares the scheduler's RCU-deferred lifetime. (cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68390", "url": "https://ubuntu.com/security/CVE-2026-68390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups hci_conn_params_lookup requires hdev->lock be held, otherwise the list iteration or param access is not safe. Hold hdev->lock for params lookups in hci_sync.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-2026-68404", "url": "https://ubuntu.com/security/CVE-2026-68404", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: use wiphy work for socket owner autodisconnect nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68367", "url": "https://ubuntu.com/security/CVE-2026-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: synchronize delayed set_alt with teardown The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68095", "url": "https://ubuntu.com/security/CVE-2026-68095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse-uring: fix race between registration and connection abortion This fixes this race: - thread a: io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref yet - thread b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() is a no-op due to queue ref being 0 - thread a: grabs the queue_ref, queue_ref is now 1, rest of fuse_uring_do_register() logic executes - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs and calls \"wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);\" The abort/unmount thread will hang indefinitely in unkillable state as nothing will decrement queue_refs or wake stop_waitq, and the ring, queue, and ent are leaked. Fix this by checking fch->connected under fch->lock after the created ent has grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either release the queue ref and wake up stop_waitq (in case fuse_chan_wait_aborted() is already waiting) in fuse_uring_do_register() when we detect !fch->connected, or if the connection is aborted after the check, it is guaranteed that the async teardown worker will be running in the background cleaning up ents and decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-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-68173", "url": "https://ubuntu.com/security/CVE-2026-68173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: wait on ublk_dev_ready() instead of ub->completion ub->completion is only re-armed by a successful START_USER_RECOVERY. If the ublk server sends END_USER_RECOVERY without one - e.g. its START failed with -EBUSY and the error was ignored - the wait is satisfied by the stale completion of the previous recovery cycle, and the device is marked LIVE and the requeue list kicked while the FETCH stream is still running and ubq->canceling is still set. The kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it again via __ublk_abort_rq(), and after the last FETCH clears ->canceling nothing ever kicks the requeue list again: the request is stranded there while holding its tag. If it is the flush machinery's flush_rq, every subsequent fsync piles up in uninterruptible sleep and teardown hangs on tag draining. This matches a report of a lost PREFLUSH with ext4 on top of ublk after daemon crash recovery. ub->completion is an edge-triggered latch used as a proxy for the level condition \"every queue has fetched all I/O commands\", which can regress (F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop it and wait on the real condition instead: the new helper ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then re-checks it under ub->mutex, waiting again on regression, and returns with the mutex held and readiness guaranteed. Readiness becomes true in the same ub->mutex critical section that clears the last queue's ->canceling, so END_USER_RECOVERY marks the device LIVE and kicks the requeue list strictly after ->canceling clears. The wait stays interruptible, so a server whose daemon died can still be signalled out. For ublk_ctrl_start_dev() this replaces the fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting until the device is ready again.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68113", "url": "https://ubuntu.com/security/CVE-2026-68113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68118", "url": "https://ubuntu.com/security/CVE-2026-68118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: challenge ACK for non-exact RST in SYN-RECEIVED The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68120", "url": "https://ubuntu.com/security/CVE-2026-68120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtase: Workaround for TX hang caused by hardware packet parsing The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission.", "cve_priority": "medium", "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-68122", "url": "https://ubuntu.com/security/CVE-2026-68122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix peer refcount leak in TCP error paths When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&peer->tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object. The race window: CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error): ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2 schedule_work() <- queued schedule_work() <- NO-OP (work already pending) ovpn_tcp_peer_del_work runs: ovpn_peer_del() ovpn_peer_put() <- refcnt+1 <- peer never freed Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68128", "url": "https://ubuntu.com/security/CVE-2026-68128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: reject out-of-range ptype in ice_parser_profile_init set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from providing ptype >= 1024 through VIRTCHNL, resulting in a write past the end of the bitmap and a kernel page fault. Reproduced with a custom kernel module injecting a crafted VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1. crash_parser: ice_parser_profile_init @ ffffffffc0d61b60 crash_parser: setting ptype=0xffff (max valid=1023) crash_parser: calling ice_parser_profile_init -- expect OOB crash! BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace: ? __pfx_ice_parser_profile_init+0x10/0x10 [ice] crash_init+0x127/0xff0 [crash_parser] do_one_initcall+0x45/0x310 do_init_module+0x64/0x270 init_module_from_file+0xcc/0xf0 idempotent_init_module+0x17b/0x280 __x64_sys_finit_module+0x6e/0xe0 Bail out early with -EINVAL when ptype is out of range.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68132", "url": "https://ubuntu.com/security/CVE-2026-68132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: super: fix emergency thaw deadlock on frozen block devices do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68133", "url": "https://ubuntu.com/security/CVE-2026-68133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP Call Trace during PTP release If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will result in the following PTP release call trace during driver unload: kernel BUG at lib/list_debug.c:52! ice_ptp_release+0x332/0x3c0 [ice] ice_deinit_features.part.0+0x10e/0x120 [ice] ice_remove+0x100/0x220 [ice] This was observed when passing PF1 through to a VM. ice_ptp_init() fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT. Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and returning without error, preventing the invalid state transition to ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from ICE_PTP_RESETTING after a failed rebuild.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68134", "url": "https://ubuntu.com/security/CVE-2026-68134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: ptp_s390: Add missing facility check Only register the physical clock when facility 28 is installed and PTFF QAF returns that PTFF QPT is available.", "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-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-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-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-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-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-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-68150", "url": "https://ubuntu.com/security/CVE-2026-68150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/super: fix emergency thaw double-unlock of s_umount do_thaw_all() iterates over all superblocks via __iterate_supers() with SUPER_ITER_EXCL, which acquires s_umount exclusively before calling the callback and releases it afterwards. However, the callback do_thaw_all_callback() calls thaw_super_locked() which unconditionally releases s_umount on every code path. This results in a second unlock attempt in __iterate_supers() that corrupts the rwsem state, triggering a DEBUG_RWSEMS warning: [ 182.601148] sysrq: Emergency Thaw of all frozen filesystems [ 182.601865] ------------[ cut here ]------------ [ 182.602375] DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff99b1011e5870, owner = 0x0, curr 0xffff99b101b06c80, list not empty [ 182.603817] WARNING: kernel/locking/rwsem.c:1412 at up_write+0xa3/0x170, CPU#2: kworker/2:1/53 [ 182.604578] Modules linked in: [ 182.604864] CPU: 2 UID: 0 PID: 53 Comm: kworker/2:1 Not tainted 7.2.0-rc4-00001-gbd3bd93ea98a-dirty #4 PREEMPT(lazy) [ 182.605711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014 [ 182.606417] Workqueue: events do_thaw_all [ 182.606750] RIP: 0010:up_write+0xaf/0x170 [ 182.607076] Code: 19 3a 92 48 0f 44 c2 48 8b 55 08 48 8b 55 00 4c 8b 45 08 48 8b 55 00 48 8d 3d ad 91 e0 01 48 8b 4d 20 50 48 c7 c6 f0 8c 26 92 <67> 48 0f b9 3a e8 d7 93 4e 00 58 eb 81 48 83 7f 18 00 48 c7 c2 8d [ 182.608563] RSP: 0018:ffffb670001d7e08 EFLAGS: 00010246 [ 182.609007] RAX: ffffffff92349e8d RBX: 0000000000000000 RCX: ffff99b1011e5870 [ 182.609595] RDX: 0000000000000000 RSI: ffffffff92268cf0 RDI: ffffffff92914d10 [ 182.610283] RBP: ffff99b1011e5870 R08: 0000000000000000 R09: ffff99b101b06c80 [ 182.610847] R10: ffff99b10139a808 R11: fefefefefefefeff R12: 0000000000000000 [ 182.611414] R13: ffffffff90cf74d0 R14: 0000000000000000 R15: ffff99b1011e5800 [ 182.612009] FS: 0000000000000000(0000) GS:ffff99b1eaaee000(0000) knlGS:0000000000000000 [ 182.612670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 182.613146] CR2: 00000000005c631c CR3: 00000000013ee000 CR4: 00000000000006f0 [ 182.613722] Call Trace: [ 182.613946] [ 182.614130] __iterate_supers+0x128/0x150 [ 182.614463] do_thaw_all+0x1b/0x30 [ 182.614759] process_scheduled_works+0xbb/0x3f0 [ 182.615150] ? __pfx_worker_thread+0x10/0x10 [ 182.615499] worker_thread+0x129/0x270 [ 182.615816] ? __pfx_worker_thread+0x10/0x10 [ 182.616201] kthread+0xe2/0x120 [ 182.616469] ? __pfx_kthread+0x10/0x10 [ 182.616792] ret_from_fork+0x15b/0x240 [ 182.617115] ? __pfx_kthread+0x10/0x10 [ 182.617426] ret_from_fork_asm+0x1a/0x30 [ 182.617761] [ 182.617968] ---[ end trace 0000000000000000 ]--- [ 182.618412] Emergency Thaw complete Fix this by switching to SUPER_ITER_UNLOCKED and acquiring s_umount in the callback via super_lock_excl() before calling thaw_super_locked(). This matches the locking pattern expected by thaw_super_locked() and eliminates the double unlock. While at it, remove the dead 'return;' at the end of do_thaw_all_callback().", "cve_priority": "low", "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-68152", "url": "https://ubuntu.com/security/CVE-2026-68152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: fix use-after-free in AMT delayed works When an AMT device is removed, pending delayed works can still access the freed amt_dev structure, which may result in kernel crashes or memory corruption. amt_dev_stop() cancels req_wq and discovery_wq with cancel_delayed_work_sync(), but these works can be scheduled again from event_wq after the cancellation. This allows delayed works to access the freed amt_dev structure after the netdev has been released. The following is a simple race scenario: CPU0 CPU1 amt_dev_stop() cancel_delayed_work_sync() amt_event_work() mod_delayed_work(req_wq) free netdev req_wq accesses freed amt_dev Use disable_delayed_work_sync() in amt_dev_stop() to prevent req_wq and discovery_wq from being queued again and wait for running work items to complete. The delayed works are disabled after initialization in amt_newlink() and enabled only when the device is successfully opened. This keeps the delayed work lifecycle synchronized with the lifetime of the AMT device.", "cve_priority": "high", "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-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-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-68168", "url": "https://ubuntu.com/security/CVE-2026-68168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix afs_edit_dir_remove() to get, not find, block 0 Fix afs_edit_dir_remove() to use afs_dir_get_block() to get block 0 rather than afs_dir_find_block() as the latter caches the found block in the afs_dir_iter and may[*] switch out the page it's on if another afs_dir_find_block() is done. This parallels what afs_edit_dir_add() does. [*] There's more than one block per page.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68169", "url": "https://ubuntu.com/security/CVE-2026-68169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: userspace: fix use-after-free in get_local_id In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a \"not found\" sentinel.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68172", "url": "https://ubuntu.com/security/CVE-2026-68172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: make huge_ptep_get handled unaligned addresses huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma). The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned. On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map or into a hole, dereference a VA not mapped into the kernel pgtables and cause kernel panic. Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68174", "url": "https://ubuntu.com/security/CVE-2026-68174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix union collision of module and refcnt for dynamic events In 'struct trace_event_call', the 'module' pointer and the 'refcnt' atomic variable share the same memory space in a union. For dynamic events, the union member is 'refcnt', which acts as an active reference counter. When a dynamic event (such as kprobe, uprobe, fprobe, eprobe, or wprobe) has a non-zero reference count (e.g. due to active event triggers or perf attachments), its 'call->module' evaluates to a small non-zero integer instead of NULL. When filtering or setting events for a specific module (e.g., writing ':mod:' to 'set_event'), the code in '__ftrace_set_clr_event_nolock()' and 'update_event_fields()' reads 'call->module' directly without checking whether the event is dynamic. This causes the kernel to treat the small integer (refcnt) as a 'struct module' pointer, leading to a NULL/invalid pointer dereference (Oops) when dereferencing the module name. Fix this by ensuring that the 'TRACE_EVENT_FL_DYNAMIC' flag is checked before treating 'call->module' as a valid pointer in these code paths.", "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-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-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-68434", "url": "https://ubuntu.com/security/CVE-2026-68434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms Commit b1b4efea05a5 (\"serial: 8250_mid: Disable DMA for selected platforms\") replaced the dnv_board setup and exit callbacks with PTR_IF(false, ...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. Fix this by adding the missing NULL checks before calling the setup and exit callbacks.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17: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-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-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16: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-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-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-68198", "url": "https://ubuntu.com/security/CVE-2026-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix use-after-free in aggr_reset_state() The aggr_reset_state() function uses timer_delete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggr_module_destroy(). If the timer callback (aggr_timeout) is executing when aggr_reset_state() is called, the callback will continue to access aggr_conn fields like rx_tid[] and stat[] which may be freed immediately after by kfree(aggr_info->aggr_conn) in aggr_module_destroy(). Additionally, the timer callback can re-arm itself via mod_timer() while aggr_reset_state() is running, creating a more complex race condition. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "high", "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-68200", "url": "https://ubuntu.com/security/CVE-2026-68200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: don't re-enter an instance callback that is still running The userspace-driven timer (utimer) TRIGGER ioctl calls snd_timer_interrupt() directly with no serialization, so two threads triggering the same utimer can run snd_timer_interrupt() on one snd_timer concurrently. snd_timer_process_callbacks() drops timer->lock around each instance callback and marks the in-flight callback with the single SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that bit to drain an in-flight callback before freeing the instance. The bit cannot represent two concurrent callbacks: when a second interrupt re-queues an instance whose callback is still running, both run at once, the first to finish clears the bit, and the close-path drain then frees the instance (and its callback_data) while the other callback is still live - a use-after-free reachable by any user able to open /dev/snd/timer, both via a user timer instance and via a sequencer queue timer bound to the utimer. snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so a concurrent interrupt already observes it under the lock. Skip re-queuing an instance (and its slaves) to the ack/sack list while its callback is in flight; the accumulated pticks are delivered on the next tick, so no event is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68201", "url": "https://ubuntu.com/security/CVE-2026-68201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: drain a slave's callback before its master detaches it snd_timer_close_locked() drains the closing instance's own in-flight callback (IFLG_CALLBACK) before freeing it, but not its slaves'. When a master instance is closed, remove_slave_links() clears each slave's ->timer; the slave's own close then reads timer == NULL and takes the branch that skips the drain entirely (snd_timer_stop_slave() also no-ops on a NULL timer). So a slave whose callback is still running when the master is closed is freed underneath the live callback, leading to use-after-free. Drain the slaves too before remove_slave_links() severs them. snd_timer_stop() has already taken this instance off the active list, so no new slave callback can be queued. Take the slaves off the ack list so a pending one can't fire either, then wait for any that is already in flight.", "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-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-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-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-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-68211", "url": "https://ubuntu.com/security/CVE-2026-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32-dcmipp: 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. dcmipp_bytecap_start_streaming() returned -EINVAL when the source subdevice could not be resolved from the media graph, before pm_runtime_resume_and_get() and media_pipeline_start() had been called. The remaining error paths already converge on the err_buffer_done label, which calls dcmipp_bytecap_all_buffers_done(..., VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate err_pm_put / err_media_pipeline_stop 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": "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-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-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-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-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-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-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-68230", "url": "https://ubuntu.com/security/CVE-2026-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: amlogic-c3: Add validations for ae and awb config Avoid invalid memory access if the zones_num is bigger than zone_weight. This patch fixes the following smatch errors: drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max", "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-68232", "url": "https://ubuntu.com/security/CVE-2026-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path.", "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-68233", "url": "https://ubuntu.com/security/CVE-2026-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Shut down BO cache timer before teardown The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20: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-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-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-68238", "url": "https://ubuntu.com/security/CVE-2026-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Release VFCT ACPI table reference amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68239", "url": "https://ubuntu.com/security/CVE-2026-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Account for NULL and handle pages in ttm_pool_backup Pages in ttm_pool_backup can be NULL or backup handles (ttm_backup_page_ptr_is_handle()), neither of which can be passed to set_pages_array_wb() or freed. Add a dedicated WB pass before the dma/purge loop that walks allocations using the same i += num_pages stride, skipping NULL and handle entries, and calls set_pages_array_wb() once per contiguous run of real pages. Apply the same NULL/handle guard to the dma/purge loop. Fixes the following oops: Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI RIP: 0010:__cpa_process_fault+0xf8/0x770 RSP: 0018:ffffc90000a87718 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34 RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0 R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000 R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0 FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0 PKRU: 55555554 Call Trace: __change_page_attr_set_clr+0x989/0xe90 ? __purge_vmap_area_lazy+0x6c/0x3a0 ? _vm_unmap_aliases+0x250/0x2a0 set_pages_array_wb+0x7f/0x120 ttm_pool_backup+0x4c9/0x5b0 [ttm] ? dma_resv_wait_timeout+0x3b/0xf0 ttm_tt_backup+0x32/0x60 [ttm] ttm_bo_shrink+0x66/0x110 [ttm] xe_bo_shrink_purge+0x12b/0x1b0 [xe] xe_bo_shrink+0xbb/0x270 [xe] __xe_shrinker_walk+0xf7/0x160 [xe] xe_shrinker_walk+0x9d/0xc0 [xe] xe_shrinker_scan+0x11f/0x210 [xe] do_shrink_slab+0x13b/0x270 shrink_slab+0xf1/0x400 shrink_node+0x352/0x8a0 balance_pgdat+0x32c/0x700 kswapd+0x205/0x2f0 ? __pfx_autoremove_wake_function+0x10/0x10 ? __pfx_kswapd+0x10/0x10 kthread+0xd1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1b1/0x200 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68241", "url": "https://ubuntu.com/security/CVE-2026-68241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/mst: limit DP MST ESI service loop The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto. (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)", "cve_priority": "medium", "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-68245", "url": "https://ubuntu.com/security/CVE-2026-68245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only valid while the lock is still being held. Once xa_unlock_irqrestore is called and returned, the pointer is no longer under lock and is subject to modification. Since, the caller still dereferences vm->task_info in amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a use after unlock problem. Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid() through removing the amdgpu_vm_get_vm_from_pasid() function from amdgpu_vm.c and making the relevant code inline to hold the lock while it is still in use. (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)", "cve_priority": "high", "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-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-68252", "url": "https://ubuntu.com/security/CVE-2026-68252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68253", "url": "https://ubuntu.com/security/CVE-2026-68253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)", "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-68257", "url": "https://ubuntu.com/security/CVE-2026-68257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix 32-bit overflow in CWSR total size calculation total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68258", "url": "https://ubuntu.com/security/CVE-2026-68258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on CRIU restore queue type and mqd size We weren't checking whether the values provided in the private data in kfd CRIU restore were within bounds. For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it. For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations. (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)", "cve_priority": "low", "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-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-68266", "url": "https://ubuntu.com/security/CVE-2026-68266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68268", "url": "https://ubuntu.com/security/CVE-2026-68268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Return error on non-migratable faults requiring devmem Non-migratable faults that require devmem incorrectly jump to the 'out' label, which squashes the error code intended to be returned to the upper layers. Fix this by returning -EACCES instead. (cherry picked from commit c4508edb2c723de93717272488ea65b165637eac)", "cve_priority": "medium", "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-68270", "url": "https://ubuntu.com/security/CVE-2026-68270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Avoid possible truncation with calculating visible size Calculating the visible size of the system framebuffer can result in truncation of the result. The calculation uses 32-bit arithmetics, which can overflow if the values for height and stride are large. Fix the issue by multiplying with mul_u32_u32().", "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-68275", "url": "https://ubuntu.com/security/CVE-2026-68275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks up the bo_va for the buffer object in the caller's VM via amdgpu_vm_bo_find(), but uses the returned pointer without checking it. amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM, which is the normal case for a BO that has never been mapped. The result is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which expands to list_for_each_entry(mapping, &(bo_va)->valids, list) and dereferences bo_va, causing a NULL pointer dereference. This is reachable by any process able to issue the ioctl (render group) simply by requesting mapping info for an unmapped BO. Return -ENOENT when no bo_va is found, jumping to out_exec so the drm_exec context and GEM object reference are released. (cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68276", "url": "https://ubuntu.com/security/CVE-2026-68276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx: fix cleaner shader IB buffer overflow The cleaner shader sysfs path allocates a 16-dword (64 byte) IB but incorrectly fills (align_mask + 1) dwords. On GFX rings align_mask is 0xff, so the loop wrote 256 dwords into a 64-byte buffer, causing a kernel page fault. The IB only needs to be a minimal NOP shell to schedule the job; the cleaner shader itself is emitted on the ring via emit_cleaner_shader(). Fill 16 dwords to match the allocation. v2: Use ib_size_dw variable (Lijo) (cherry picked from commit bf21af331ebf72d0935fd70c73192414a422c03a)", "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-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-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-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-68282", "url": "https://ubuntu.com/security/CVE-2026-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: analogix_dp: Add missing error check for platform_get_resource() Add missing error check for platform_get_resource() return value to prevent NULL pointer dereference when memory resource is not available.", "cve_priority": "medium", "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-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-68292", "url": "https://ubuntu.com/security/CVE-2026-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues.", "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-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-68296", "url": "https://ubuntu.com/security/CVE-2026-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM Before commit 00d066a4d4ed (\"netdev_features: convert NETIF_F_LLTX to dev->lltx\"), NETIF_F_LLTX was set unconditionally in both __gre_tunnel_init() and ip6gre_tnl_init_features() alongside GRE_FEATURES: dev->features |= GRE_FEATURES | NETIF_F_LLTX; When that commit converted NETIF_F_LLTX to the dev->lltx flag, it placed 'dev->lltx = true' after the SEQ/CSUM early returns instead of before them. This causes GRE/GRETAP/ip6gre tunnels with SEQ or CSUM+encap to lose lockless TX, reintroducing _xmit_lock acquisition around their ndo_start_xmit. Since GRE xmit re-enters the stack via ip_tunnel_xmit(), holding _xmit_lock risks ABBA deadlock with the underlay device. CPU0 CPU1 ---- ---- lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); Fix by moving dev->lltx = true before the early returns in both functions, restoring the original unconditional behavior.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64575", "url": "https://ubuntu.com/security/CVE-2026-64575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: fix double sock release on batch realloc bpf_iter_tcp_batch() releases the current batch via bpf_iter_tcp_put_batch(), which drops the socket refs and rewrites each slot with the socket cookie, then grows the batch. cur_sk/end_sk are kept for bpf_iter_tcp_resume(), but on realloc failure the function returns ERR_PTR() before resume runs, leaving cur_sk < end_sk over slots that now hold cookies rather than sock pointers. bpf_iter_tcp_seq_stop() then calls bpf_iter_tcp_put_batch() again and dereferences a cookie as a struct sock. Empty the batch on the failure path so stop() does not release it again. The sockets were already freed by the first bpf_iter_tcp_put_batch(), so nothing leaks, and a later read() rescans the bucket from the start instead of skipping it. The sibling GFP_NOWAIT failure path still holds real socket references and is left for stop() to release. BUG: KASAN: null-ptr-deref in __sock_gen_cookie Read of size 8 at addr 0000000000000059 by task exploit ... __sock_gen_cookie (net/core/sock_diag.c:28) bpf_iter_tcp_put_batch (net/ipv4/tcp_ipv4.c:2918) bpf_iter_tcp_seq_stop (net/ipv4/tcp_ipv4.c:3270) bpf_seq_read (kernel/bpf/bpf_iter.c:205) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 entry_SYSCALL_64_after_hwframe Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68298", "url": "https://ubuntu.com/security/CVE-2026-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create() Commit 9e9787414882 (\"drm/xe/userptr: replace xe_hmm with gpusvm\") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a \"simple\" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). (cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4)", "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-68448", "url": "https://ubuntu.com/security/CVE-2026-68448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: check access to copy_file_range source with src mounter creds Commit 5dae222a5ff0c (\"vfs: allow copy_file_range to copy across devices\") allowed filesystems that implement the copy_file_range() f_op to decide if they want to access cross-sb copy from/to the same fs type. The same commit added checks to verify same sb copy for filesystems that implement ->copy_file_range() and do not support cross-sb copy at the time, namely, to ceph, fuse and nfs. The two remaining fs which implement ->copy_file_range(), cifs and overlayfs started to support cross-sb copy from this time. While overlayfs does support cross-sb copy when the two underlying files are on the same base fs, the copy operation on the two real files from two different overalyfs filesystems is performed with the mounter creds of the destination overlayfs and the read permission access hook for the source file was called with the wrong creds. This could cause either deny of access to copy which would otherwise be allowed (e.g. with splice) or allow read access to file which would otherwise be denied. Fix the latter case by explicitly verifying read access to source file with the source overlayfs mounter creds. The former case remains a quirk of cross-sb overlayfs copy, but userspace could fall back to regular copy so no harm done.", "cve_priority": "low", "cve_public_date": "2026-08-12 01:17: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-68307", "url": "https://ubuntu.com/security/CVE-2026-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix crash in reset link replay During reset recovery, mt7925_vif_connect_iter() replays firmware state for links tracked in mvif->valid_links. After MLO link changes or MCU timeout recovery, the driver bitmap can temporarily contain a link whose mac80211 bss_conf has already gone away. This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching the crash where x1, the second argument, is NULL: pc : mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] lr : mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] x2 : ffffff80a77f6018 x1 : 0000000000000000 x0 : ffffff8099402080 Call trace: mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common] Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA reset replay is unchanged because the helper still returns &vif->bss_conf for the legacy link.", "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-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-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-68311", "url": "https://ubuntu.com/security/CVE-2026-68311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: guard link STA in decap offload mt7925_sta_set_decap_offload() iterates over the vif valid_links mask when updating decap offload state for an MLO station. The station may not have a link STA for every valid link of the vif, so mt792x_sta_to_link() can return NULL for a link that belongs to the vif but not to the station. The function currently dereferences mlink before checking whether the link WCID is ready. If mlink is NULL, setting or clearing MT_WCID_FLAG_HDR_TRANS dereferences a NULL pointer. Skip links without a station link before touching mlink->wcid.", "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-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-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-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-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-68321", "url": "https://ubuntu.com/security/CVE-2026-68321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix FDIR filter leak on remove Perfect FDIR filters can be added while the interface is down and are kept on the software list for later restore. unregister_netdev() only calls ndo_stop when the device is up, so txgbe_fdir_filter_exit() in txgbe_close() is skipped in that case and the filters are leaked on driver remove. Free the filter list from txgbe_remove() as well.", "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-68330", "url": "https://ubuntu.com/security/CVE-2026-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix DMA direction for NPU mailbox buffer airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE, but some callers expect the NPU to write response data back into the same buffer: - airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into the buffer, then the caller reads it via memcpy() - airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back npu_stats_addr field in the response On non-cache-coherent architectures like EN7581 (Cortex-A53 without hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op — it does not invalidate the CPU cache. If the NPU-written cache line is still present in the CPU cache when the caller reads the buffer, the CPU observes stale data instead of the NPU response. This is a timing-sensitive bug: small mailbox buffers (~24 bytes) typically fit in a single cache line and may survive in the cache until the caller reads them, producing silent data corruption rather than a crash. The bug is more likely to trigger when the caller reads the response immediately after dma_unmap_single() without intervening cache-evicting operations. Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures dma_unmap_single() invalidates the CPU cache on non-coherent systems. The mailbox buffers are small so there is no performance concern.", "cve_priority": "low", "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-68332", "url": "https://ubuntu.com/security/CVE-2026-68332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix potential use-after-free in airoha_ppe_deinit() airoha_ppe_deinit() replaces the NPU pointer with NULL via rcu_replace_pointer() but does not wait for existing RCU readers to exit before calling ppe_deinit() and airoha_npu_put(). This can cause a use-after-free if a reader in an RCU read-side critical section still holds a reference to the NPU when it is freed. The init path (airoha_ppe_init) already calls synchronize_rcu() after rcu_assign_pointer(), but the deinit path introduced in commit 6abcf751bc08 (\"net: airoha: Fix schedule while atomic in airoha_ppe_deinit()\") omitted the matching barrier when switching from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer(). Add synchronize_rcu() before ppe_deinit() to ensure all existing RCU readers have completed before the NPU resources are released.", "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-68334", "url": "https://ubuntu.com/security/CVE-2026-68334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix io_thread race in rxrpc_wake_up_io_thread() rxrpc_wake_up_io_thread() checks local->io_thread before waking it, but then reloads the pointer for wake_up_process(). local->io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so the second load can see NULL even if the first load did not. Take a READ_ONCE() snapshot and use it for both the NULL check and the wake_up_process() call, as rxrpc_encap_rcv() already does.", "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-68341", "url": "https://ubuntu.com/security/CVE-2026-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix use after free in unlock_ovpn() unlock_ovpn() iterates over the release_list using llist_for_each_entry() and drops the peer reference inside the loop body via ovpn_peer_put(). If this drops the last reference, the peer is eventually freed. However, llist_for_each_entry() reads peer->release_entry.next in the loop advance expression, which runs after the body. By that time the peer may have already been freed, resulting in a use after free when advancing to the next list entry. Fix this by using llist_for_each_entry_safe(), which caches the next pointer before executing the loop body.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68342", "url": "https://ubuntu.com/security/CVE-2026-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: avoid putting unrelated P2P peer on socket release ovpn_peer_release_p2p() is called when an OVPN UDP socket is being destroyed. It checks the currently published P2P peer and releases it only if that peer still uses the socket being destroyed. A peer replacement can publish a new peer before the old UDP socket is destroyed. When the old socket destruction path runs afterwards, ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the new peer uses a different socket, the function takes the socket mismatch branch. That branch still calls ovpn_peer_put(peer). At this point, however, peer is the currently published replacement peer, not the peer associated with the socket being destroyed. Dropping its reference can free it while ovpn->peer still points to it, leading to later use-after-free accesses from the peer and socket cleanup paths. KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer object. In the reproducer, the object is allocated from ovpn_peer_new() via ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU callback processing. Observed access sites include ovpn_peer_remove(), ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn(). Fix this by returning from the socket mismatch branch without putting the peer.", "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-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-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-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-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-68356", "url": "https://ubuntu.com/security/CVE-2026-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: airoha: Prevent division by zero when clock frequency is zero clk_get_rate() can return 0 when the clock provider is not properly configured or the clock is unmanaged. The driver uses wdt_freq as a divisor directly in airoha_wdt_probe() to compute max_timeout and in airoha_wdt_get_timeleft() to compute the remaining time, which results in a division by zero. Add a check for wdt_freq == 0 in probe and return -EINVAL with dev_err_probe() to prevent the division by zero and provide a diagnostic message.", "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-68358", "url": "https://ubuntu.com/security/CVE-2026-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-kraken3) 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-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-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-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-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-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-68374", "url": "https://ubuntu.com/security/CVE-2026-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: sysfs: add lock to bos_descriptors_read() Add a lock to the function bos_descriptors_read(). This function accesses udev->bos, which could be simultaneously freed in usb_reset_and_verify_device(), a function that is commonly called in drivers all over the kernel.", "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-68378", "url": "https://ubuntu.com/security/CVE-2026-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions: - A pin is registered with two or more dpll devices (dpll_A, dpll_B) - The pin has ref_sync pairs with other pins - During unregistration of dpll_A's pins, a ref_sync partner pin is unregistered first, removing it from dpll_A->pin_refs - But since the partner pin is still registered with dpll_B, its dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT run and the partner stays in the pin's ref_sync_pins xarray - When the pin itself is then unregistered from dpll_A, the delete notification calls dpll_msg_add_pin_ref_sync() which finds the partner in ref_sync_pins, passes dpll_pin_available() (partner is still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A, partner) returns NULL because partner was already removed from dpll_A->pin_refs - The NULL priv pointer is passed to the driver's ref_sync_get callback, which dereferences it BUG: kernel NULL pointer dereference, address: 0000000000000034 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x] Call Trace: dpll_msg_add_pin_ref_sync+0xb8/0x200 dpll_cmd_pin_get_one+0x3b6/0x4b0 dpll_pin_event_send+0x72/0x140 __dpll_pin_unregister+0x5a/0x2b0 dpll_pin_unregister+0x49/0x70 Fix this by skipping ref_sync pins whose priv pointer cannot be resolved for the current dpll device.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68379", "url": "https://ubuntu.com/security/CVE-2026-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix TIME_WAIT socket reference leak on PSP policy failure Release the TIME_WAIT socket reference and jump to discard_it upon PSP policy failure in both IPv4 and IPv6 receive paths. This prevents a memory leak of tcp_tw_bucket structures.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68380", "url": "https://ubuntu.com/security/CVE-2026-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix use-after-free of mm_struct in job scheduler amdxdna_cmd_submit() stores current->mm in job->mm without holding any reference. aie2_sched_job_run() later access job->mm from the DRM scheduler worker thread. With only a raw pointer and no structural reference, the mm_struct can be freed before the scheduler runs the job. Fix this by calling mmgrab() to hold a structural mm_count reference for the lifetime of the job, paired with mmdrop() in every cleanup path.", "cve_priority": "high", "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-68384", "url": "https://ubuntu.com/security/CVE-2026-68384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits. - Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it. While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one. (cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68385", "url": "https://ubuntu.com/security/CVE-2026-68385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/checksum: Fix csum_partial() without vector facility Currently csum_partial() calls csum_copy() with copy=false and dst=NULL. On machines without the vector facility, csum_copy() falls back to cksm(dst, ...), causing the checksum to be calculated from address zero instead of the source buffer. The VX implementation already checksums data loaded from src. Make the fallback do the same by passing src to cksm().", "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-68387", "url": "https://ubuntu.com/security/CVE-2026-68387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: add locking for raw flags bitfield With commit 890e5198a6e5 (\"can: raw: use bitfields to store flags in struct raw_sock\") the formerly separate integer values have been integrated into a single bitfield. This led to a read-modify-write operation when changing a flag in raw_setsockopt() which now needs a locking to prevent concurrent access. Instead of adding a lock/unlock hell in each of the flag manipulations this patch introduces a wrapper for a new raw_setsockopt_locked() function analogue to the isotp_setsockopt[_locked]() approach in net/can/isotp.c [mkl: use Closes tag instead of Link]", "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-68393", "url": "https://ubuntu.com/security/CVE-2026-68393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: extend conn_hash lookup critical sections Using RCU-protected pointers outside the critical sections without refcount is incorrect and may result to UAF. Extend critical section to cover both hci_conn_hash lookup and use of the returned conn. Add surrounding rcu_read_lock() also when return value is not used, in preparation for RCU lockdep requirement to hci_lookup_le_connect(). This avoids concurrent deletion of the conn before we are done dereferencing it. Also, make sure to hold hdev->lock when accessing hdev->accept_list.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68394", "url": "https://ubuntu.com/security/CVE-2026-68394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update MGMT_OP_LOAD_CONN_PARAM queues conn_update_sync() when a single parameter update changes an existing LE central connection. The queued work currently stores a borrowed hci_conn_params entry from hdev->le_conn_params. A later LOAD_CONN_PARAM request can clear disabled parameters and free that entry before hci_cmd_sync_work() runs the queued callback. Do not keep the borrowed hci_conn_params pointer in queued work. Queue the hci_conn instead and hold a reference until the queued callback completes. When the work runs, revalidate that the connection is still present, look up the current hci_conn_params entry, and cancel the update if userspace removed that entry while the work was pending. Copy the interval values from the current params entry under hdev->lock, then drop the lock and keep using hci_le_conn_update_sync() to issue the update. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in conn_update_sync+0x2a/0xf0 [bluetooth] Read of size 1 at addr ffff88810c697126 by task kworker/u17:0/377 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 kasan_report+0xe0/0x110 conn_update_sync+0x2a/0xf0 [bluetooth] hci_cmd_sync_work+0x187/0x210 [bluetooth] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 Allocated by task 466: hci_conn_params_add+0xa6/0x240 [bluetooth] load_conn_param+0x4e1/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] Freed by task 474: kfree+0x313/0x590 hci_conn_params_clear_disabled+0x9b/0xc0 [bluetooth] load_conn_param+0x4bf/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth]", "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-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-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-68400", "url": "https://ubuntu.com/security/CVE-2026-68400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint memory access array and to comply with the FF-A spec instead of defaulting to `sizeof(struct ffa_mem_region)`. This requires moving `ffa_mem_region_additional_setup()` earlier in the setup flow. Also, add sanity checks to ensure the calculated descriptor offsets do not exceed `max_fragsize`.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68401", "url": "https://ubuntu.com/security/CVE-2026-68401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() Sashiko (locally) reports multiple out-of-bound issues in ffa_setup_and_transmit: 1) Writing ep_mem_access->reserved can write out of bounds for FFA versions < 1.2 as ffa_emad_size_get() returns 16 bytes in that case while reserved has an offset of 24. Instead of zeroing fields, memset the struct to zero first based on the FFA version. 2) Make sure there is enough size to write constituents. While at it, convert the only sizeof() in the driver that uses a type instead of variable.", "cve_priority": "high", "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-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-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-68409", "url": "https://ubuntu.com/security/CVE-2026-68409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: defer link RX stats percpu free to RCU sta_remove_link() frees a removed MLO link's RX stats percpu buffer right away, but defers only the link container to RCU: \tsta_info_free_link(&alloc->info); \tkfree_rcu(alloc, rcu_head); The RX fast path reads link_sta under rcu_read_lock and writes the percpu stats. A reader that resolved link_sta before the removal keeps the pointer. The container stays alive from the kfree_rcu, so the read still works. But the percpu block it points to is already freed. This needs uses_rss. That is when pcpu_rx_stats exists. The full STA teardown frees the deflink stats only after synchronize_net(). The link removal path had no such barrier. The race is hard to win in practice, but the free should still wait for RCU. Free the link together with its data from a single RCU callback, so the percpu block is reclaimed only after readers drain.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20: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-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-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-68412", "url": "https://ubuntu.com/security/CVE-2026-68412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan() If the test against IEEE80211_MAX_SSID_LEN fails, then 'creq' leaks. Use the existing error handling path to fix it.", "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-64566", "url": "https://ubuntu.com/security/CVE-2026-64566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags() When iptfs_skb_add_frags() copies frag references from the source frag walk into a new SKB, it increments the page reference count via __skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the destination SKB's skb_shinfo->flags. If the source SKB carries shared frags (e.g. from a page-pool backed receive path), the new inner SKB will appear to ESP as having privately owned frags. A subsequent esp_input() call for a nested transport-mode SA then takes the no-COW fast path and decrypts in place, writing over pages that are still referenced by the outer IPTFS SKB. This causes kernel-visible memory corruption and can trigger a panic. All other frag-transfer helpers in the kernel (skb_try_coalesce, skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this convention by setting the flag inside the loop immediately after __skb_frag_ref() and nr_frags++, so every exit path that attaches a frag unconditionally propagates SKBFL_SHARED_FRAG.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68415", "url": "https://ubuntu.com/security/CVE-2026-68415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear mode callbacks after failed mode setup xfrm_state_gc_task can run long after a failed IPTFS state setup. In the reproduced case, __xfrm_init_state() cached x->mode_cbs, IPTFS setup returned -ENOMEM before publishing mode_data, and the temporary module reference from xfrm_get_mode_cbs() was dropped immediately. The dead state then kept x->mode_cbs until deferred GC ran after xfrm_iptfs had been unloaded. Clear x->mode_cbs when mode init or clone fails before publishing mode_data. Those states never installed mode-specific state or the long-term IPTFS module pin, so deferred GC has nothing mode-specific to destroy and must not retain a callback table pointer past the temporary lookup reference. The buggy scenario involves two paths, with each column showing the order within that path: failed setup path: 1. cache x->mode_cbs 2. mode setup fails before mode_data 3. drop the temporary module ref 4. dead state keeps x->mode_cbs cached GC/unload path: 1. xfrm_state_put() queues GC work 2. xfrm_iptfs unloads later 3. xfrm_state_gc_task runs 4. GC dereferences stale x->mode_cbs This also covers the failed clone path where clone_state() returns before publishing mode_data. Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y failslab_stacktrace_filter matched xfrm_iptfs frames ack_error=-12 FAULT_INJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrm_state_gc_task RIP: xfrm_state_gc_task+0x142/0x650 Modules linked in: esp4_offload xfrm_user [last unloaded: xfrm_iptfs] Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68418", "url": "https://ubuntu.com/security/CVE-2026-68418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent user-triggered null deref on QP create Previously, the user QP creation path would only attempt to populate iwqp->iwpbl if the user-provided req.user_wqe_bufs field was non-zero. The problem is that iwqp->iwpbl is unconditionally dereferenced later on in irdma_setup_virt_qp. While there was a check for iwqp->iwpbl != NULL, this check would only occur if req.user_wqe_bufs was non-zero. The end result is that a user could send a zero user_wqe_bufs value and trigger a null ptr deref. Fix this by unconditionally calling irdma_get_pbl and bailing if it fails, similar to the CQ and SRQ paths.", "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-68420", "url": "https://ubuntu.com/security/CVE-2026-68420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: reject optional IPTFS templates in outbound policies syzbot reported a stack-out-of-bounds read in xfrm_state_find() which flows from xfrm_tmpl_resolve_one(). Commit 3d776e31c841 (\"xfrm: Reject optional tunnel/BEET mode templates in outbound policies\") disallowed optional tunnel and BEET in outbound policies to prevent this. Later when IPTFS added, it was not covered by that fix and can still trigger the out-of-bounds read; Extend the check to disallow optional IPTFS in outbound policies as well. IPTFS should be identical to tunnel mode. IN and FWD policies are not affected: xfrm_tmpl_resolve_one() is only reachable via the outbound path. Reproducer, before: ip link add dummy0 type dummy ip link set dummy0 up ip addr add 10.1.1.1/24 dev dummy0 ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 mode transport ping -W 1 -c 1 10.1.1.2 PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data. [ 64.168420] ================================================================== [ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844 [ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full) [ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 64.169977] Call Trace: [ 64.169977] [ 64.169977] dump_stack_lvl+0x47/0x70 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] print_report+0x152/0x4b0 [ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0 [ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20 [ 64.169977] ? __virt_addr_valid+0x21b/0x230 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] kasan_report+0xa8/0xd0 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm_dst_hash+0x24/0xc0 [ 64.169977] xfrm_state_find+0xa2d/0x2f90 [ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570 [ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10 [ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 64.169977] ? kernel_text_address+0x5b/0x80 [ 64.169977] ? __kernel_text_address+0xe/0x30 [ 64.169977] ? unwind_get_return_address+0x5e/0x90 [ 64.169977] ? arch_stack_walk+0x8c/0xe0 [ 64.169977] xfrm_tmpl_resolve+0x130/0x200 [ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10 [ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110 [ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10 [ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310 [ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80 [ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10 [ 64.169977] ? ip_route_output_key_hash+0xc6/0x110 [ 64.169977] ? kasan_save_track+0x10/0x30 [ 64.169977] xfrm_lookup_route+0x18/0xe0 [ 64.169977] ip4_datagram_release_cb+0x4c9/0x530 [ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10 [ 64.169977] ? do_raw_spin_lock+0x71/0xc0 [ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 64.169977] release_sock+0xb0/0x170 [ 64.169977] udp_connect+0x43/0x50 [ 64.169977] __sys_connect+0xa6/0x100 [ 64.169977] ? alloc_fd+0x2e9/0x300 [ 64.169977] ? __pfx___sys_connect+0x10/0x10 [ 64.169977] ? preempt_latency ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68421", "url": "https://ubuntu.com/security/CVE-2026-68421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx() put_prev_task_scx() warns when a runnable task drops to a lower sched_class without SCX_OPS_ENQ_LAST, on the assumption that balance_one() would have kept it running. Core scheduling breaks that: a forced-idle SMT sibling reschedules through the core_pick fast path in pick_next_task(), which skips pick_task_scx() and thus balance_one(), so a runnable task can drop to idle with ENQ_LAST unset. Gate the warning on sched_cpu_cookie_match(): a cookie mismatch means core scheduling forced the idle, while a match (or core scheduling off) still catches a genuine missing-ENQ_LAST drop.", "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-68426", "url": "https://ubuntu.com/security/CVE-2026-68426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix stale skb->prev after async crypto steals a GSO segment skb_gso_segment() leaves the segment list head with ->prev pointing at the last segment, an invariant validate_xmit_skb_list() relies on when it sets its tail pointer (tail = skb->prev). When validate_xmit_xfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validate_xmit_skb_list() later does tail->next = skb, writing through that stale pointer -- a use-after-free. Repoint skb->prev at the last retained segment before returning.", "cve_priority": "critical", "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-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-2023-20585", "url": "https://ubuntu.com/security/CVE-2023-20585", "cve_description": "Insufficient checks of the RMP on host buffer access in IOMMU may allow an attacker with privileges and a compromised hypervisor to trigger an out of bounds condition without RMP checks, resulting in a potential loss of confidential guest integrity.", "cve_priority": "low", "cve_public_date": "2026-04-16 19:16:00 UTC" }, { "cve": "CVE-2026-68364", "url": "https://ubuntu.com/security/CVE-2026-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix ISM dc_lock deadlock during suspend [Why] System hang observed during suspend/resume while video is playing. amdgpu_dm_ism_disable() is called under dc_lock and waits for ISM delayed work via disable_delayed_work_sync(). The work handlers themselves take dc_lock, producing an ABBA deadlock when a worker is in flight at suspend time. [How] Split the disable path into two phases with opposite locking contracts: 1. amdgpu_dm_ism_disable() -- quiesces workers, must NOT hold dc_lock. 2. amdgpu_dm_ism_force_full_power() (new) -- drives the ISM FSM back to FULL_POWER_RUNNING, must hold dc_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72064", "url": "https://ubuntu.com/security/CVE-2026-72064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Sync page pool RX frags for CPU MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack.", "cve_priority": "medium", "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-72098", "url": "https://ubuntu.com/security/CVE-2026-72098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: fix buffer overflow in FEC calculation There's a buffer overflow in dm-verity-fec: if (neras && *neras <= v->fec->roots) \tfio->erasures[(*neras)++] = i; This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72248", "url": "https://ubuntu.com/security/CVE-2026-72248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: support IPIP tunnel with direct xmit The combination of IPIP tunnel with direct xmit, eg. bridge device, breaks because no dst_entry is provided to check the skb headroom and to set the iph->frag_off field. This leads to invalid dst usage and can trigger a crash in the tunnel transmit path. Fix this by moving dst_cache and dst_cookie out of the runtime union so that they can be shared by neighbour, xfrm, and direct tunnel flows. For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve route state in these shared fields and release it through the common dst release path. Since dst_entry is now available to the three supported xmit modes and dst_release() already deals with NULL dst, remove the xmit type check in nft_flow_dst_release(). Moreover, skip the check if the dst entry is NULL in nf_flow_dst_check() which is now the case for the direct xmit case. Based on patch from Rein Wei .", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72249", "url": "https://ubuntu.com/security/CVE-2026-72249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: use dst in this direction when pushing IPIP header When pushing the IPIP header, the route of the other direction is used to calculate the headroom, use the route in this direction. Accessing the other tuple to set the IP source and destination is fine because this tuple does not provide such information to avoid storing redundant information. However, this tuple already provides the dst for this direction, this went unnoticed because this bug affects headroom and iph->frag_off only at this stage.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72287", "url": "https://ubuntu.com/security/CVE-2026-72287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the \"normal\" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a \"late\" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72329", "url": "https://ubuntu.com/security/CVE-2026-72329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/liquidio: drop cached VF pci_dev LUT The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST. Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72355", "url": "https://ubuntu.com/security/CVE-2026-72355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix barriering when walking subrequest list Fix the barriering used when walking the subrequest list in retry as there's a possibility of seeing a subreq that's just been added by the application thread.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72412", "url": "https://ubuntu.com/security/CVE-2026-72412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/mm: Fix handling of _PAGE_UNUSED pte bit The _PAGE_UNUSED softbit should not really be lying around. Its sole purpose is to signal to try_to_unmap_one() and try_to_migrate_one() that the page can be discarded instead of being moved / swapped. KVM has no way to know why a page is being unmapped, so it sets the bit on userspace ptes corresponding to unused guest pages every time they get unmapped. KVM has no reasonable way to clear the bit once the page is in use again. While set_ptes() checks and clears the bit, other paths that set new ptes did not. This led to used pages being thrown out as if they were unused, causing guest corruption. Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in set_pte(), i.e. whenever a present pte is getting set. The check in set_ptes() is then redundant and can be removed. Also fix gmap_helper_try_set_pte_unused() to only set the bit if the pte is present; the _PAGE_UNUSED bit is only defined for present ptes and thus should not be set for non-present ptes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72417", "url": "https://ubuntu.com/security/CVE-2026-72417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto() Add sanity check for iph->ihl field in nf_flow_ip4_tunnel_proto() before using it to compute the header size, avoiding out-of-bounds access with malformed IP headers. While at it, use iph->protocol instead of the hardcoded IPPROTO_IPIP constant when setting ctx->tun.proto and reference ctx->tun.hdr_size when updating ctx->offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72442", "url": "https://ubuntu.com/security/CVE-2026-72442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: fix and simplify IP6IP6 tunnel handling Fix nf_flow_ip6_tunnel_proto() to use pskb_may_pull() instead of skb_header_pointer() to ensure the outer IPv6 header is in the skb headroom, which is required for subsequent packet processing. Move ctx->offset update inside the IPPROTO_IPV6 conditional block since it should only be adjusted when an IP6IP6 tunnel is actually detected. Simplify the rx path by removing ipv6_skip_exthdr() and checking ip6h->nexthdr directly, as the flowtable fast path only handles simple IP6IP6 encapsulation without extension headers. Drop the tunnel encapsulation limit destination option support from the tx path to match, since the rx path no longer handles extension headers. Remove the encap_limit parameter from nf_flow_offload_ipv6_forward(), nf_flow_tunnel_ip6ip6_push() and nf_flow_tunnel_v6_push(), along with the ipv6_tel_txoption struct and related headroom/MTU adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72463", "url": "https://ubuntu.com/security/CVE-2026-72463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix dev use-after-free in xfrm async resumption xfrm async resumption hold skb->dev refcnt until after transport_finish. However, xfrm_rcv_cb may modify skb->dev to tunnel dev without taking device reference, such as vti_rcv_cb. The subsequent async resumption will decrement the tunnel device's reference count, which lead to uaf of tunnel dev and refcnt leak of orig dev as below: unregister_netdevice: waiting for vti1 to become free. Usage count = -2 Stash the original skb->dev to fix refcnt imbalance. The new skb->dev set by xfrm_rcv_cb can race with device teardown. Extend rcu protection over xfrm_rcv_cb and transport_finish to prevent races.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72477", "url": "https://ubuntu.com/security/CVE-2026-72477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: call _ntfs_bad_inode() when failing to rename It is safe to call _ntfs_bad_inode on live inodes since: commit 519b078998ce (\"fs/ntfs3: Exclude call make_bad_inode for live nodes.\") The WARN_ON was added when it wasn't safe by: commit d99208b91933 (\"fs/ntfs3: cancle set bad inode after removing name fails\") Replace the WARN_ON with a call to _ntfs_bad_inode() to prevent further operations on the inconsistent inode.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72493", "url": "https://ubuntu.com/security/CVE-2026-72493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: serialize netif_running() check in enqueue_to_backlog() Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup(). The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit). Commit e9e4dd3267d0 (\"net: do not process device backlog during unregistration\") introduced a lockless netif_running() check in enqueue_to_backlog() to prevent queuing packets to an unregistering device. However, this creates a TOCTOU race window. A lockless transmitter (like veth_xmit) can pass the check before dev_close() clears IFF_UP. If the transmitter is then delayed, flush_all_backlogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed. Fix this by moving the netif_running() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netif_running() after the flush/close completes (so it gets dropped).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72494", "url": "https://ubuntu.com/security/CVE-2026-72494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Replace waitqueue and flag with completion The driver previously used a waitqueue along with an explicit request_done flag, but without proper barriers around request_done. An earlier patch by Gui-Dong Han attempted to fix this by adding the missing memory barriers. Rather than adding the barriers, this patch replaces the waitqueue+flag with a completion, which is designed for this exact purpose.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72496", "url": "https://ubuntu.com/security/CVE-2026-72496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Proper rollback if the ioremap fails bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74269", "url": "https://ubuntu.com/security/CVE-2026-74269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt: fix head underflow on XDP head-grow The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free. The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with this commit applied causes the test to run successfully to completion. The other rx_skb_func implementations don't have this issue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74350", "url": "https://ubuntu.com/security/CVE-2026-74350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate fast symlink target during inode read ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment. A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer. Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated. This keeps malformed fast symlinks from reaching the read path. Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x19f/0x330 (?:?) kasan_report+0xe0/0x110 (?:?) kasan_check_range+0x105/0x1b0 (?:?) __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72495", "url": "https://ubuntu.com/security/CVE-2026-72495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid repeated requests to allocate WC pages Applications can request multiple WC pages for the same ucontext. As of now, only 1 WC page per ucontext is supported. Add a lock to avoid concurrent access and a check to fail repeated requests. Also, if the mmap entry insert fails for the WC, free the Doorbell page index mapped for the WC page.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72501", "url": "https://ubuntu.com/security/CVE-2026-72501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Initialize dpi variable to zero dpi is initialized only for BNXT_RE_ALLOC_WC_PAGE, but copied for all the cases. So initialize the dpi to 0.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72278", "url": "https://ubuntu.com/security/CVE-2026-72278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Re-translate VNCR before injecting abort KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor updates and MMU faults.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68083", "url": "https://ubuntu.com/security/CVE-2026-68083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix path resolution in ksmbd_vfs_kern_path_create The SMB2 open lookup is rooted at the share with LOOKUP_BENEATH, but the create/mkdir/hardlink sink is not: ksmbd_vfs_kern_path_create() builds an absolute path with convert_to_unix_name() and resolves it from AT_FDCWD via start_creating_path(), so a \"..\" component is walked from the real filesystem root and escapes the export. An authenticated client races a missing path component so the rooted open lookup returns -ENOENT (taking the create branch) while the same component is present (a directory) when the create walk runs; the create then resolves \"..\" out of the share. Root the create walk at the share like the lookup and rename paths already are: resolve the parent with vfs_path_parent_lookup(..., LOOKUP_BENEATH, &share_conf->vfs_path) and create the final component with start_creating_noperm(). convert_to_unix_name() then has no callers and is removed.", "cve_priority": "high", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-68457", "url": "https://ubuntu.com/security/CVE-2026-68457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use opener credentials for FSCTL mutations SET_SPARSE, SET_ZERO_DATA and SET_COMPRESSION operate on an open SMB handle but call VFS xattr, fallocate or fileattr helpers with the current ksmbd worker credentials. Those helpers can revalidate inode permissions, ownership and LSM policy independently of the SMB handle access mask. Run each operation with the credentials captured in the target file when the handle was opened. Keep credential handling local to these single-file FSCTLs rather than applying session credentials to the complete IOCTL handler, which also contains handle-less and multi-handle operations.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72041", "url": "https://ubuntu.com/security/CVE-2026-72041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: use sk_msg_free_partial to fix partial send sk_msg_free_partial() ensures consistency of the skmsg at every iteration, without having to manually handle uncharges and offsets. This simplifies the code, and fixes some bugs in skmsg accounting when we don't send the full contents.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72046", "url": "https://ubuntu.com/security/CVE-2026-72046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing.", "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-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21: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-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72137", "url": "https://ubuntu.com/security/CVE-2026-72137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: nat_keepalive: avoid double free on send error nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6 send helper reports an error. That cleanup is only correct before the skb is handed to the output path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the networking stack may already have consumed the skb before returning an error, so freeing it again is unsafe. Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4() and nat_keepalive_send_ipv6(), where the caller still owns the skb, and keep nat_keepalive_send() responsible only for family dispatch and the unsupported-family cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72139", "url": "https://ubuntu.com/security/CVE-2026-72139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: defer md5sig_info kfree past RCU grace period in tcp_connect The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: \tif (needs_md5) { \t\ttcp_ao_destroy_sock(sk, false); \t} else if (needs_ao) { \t\ttcp_clear_md5_list(sk); \t\tkfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); \t} Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with tcp-diag]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72191", "url": "https://ubuntu.com/security/CVE-2026-72191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: validate split-point offset in indx_insert_into_buffer indx_insert_into_buffer() computes used = used1 - to_copy - sp_size; memmove(de_t, Add2Ptr(sp, sp_size), used - le32_to_cpu(hdr1->de_off)); where sp and sp_size come from hdr_find_split(). hdr_find_split() walks entries by le16_to_cpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFS_DE). index_hdr_check(), the on-load gatekeeper, only validates header-level fields (used, total, de_off) and does not walk per-entry sizes. A crafted NTFS image whose leaf INDEX_HDR reports used == total but contains one interior NTFS_DE with size = 0xFFF0 therefore passes validation, descends to indx_insert_into_buffer() through the ntfs_create() -> indx_insert_entry() path, and makes hdr_find_split() return an sp whose sp_size (0xFFF0) greatly exceeds the remaining bytes in the buffer. The u32 subtraction underflows and the memmove count becomes a near-4-GiB value, producing an out-of-bounds kernel write that corrupts adjacent allocations and panics the kernel. Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a single 'touch' inside the mounted directory; crash site resolves to fs/ntfs3/index.c at the memmove. Trigger requires only local mount of an attacker-supplied filesystem image (USB, loopback, or removable media auto-mount). Reject the split whenever the chosen sp plus its declared size already extends past hdr1->used. This is the minimal fix; it preserves the existing hdr_find_split() contract and relies on the same out: cleanup path as the pre-existing error returns. A prior OOB read in the very same indx_insert_into_buffer() memmove was fixed in commit b8c44949044e (\"fs/ntfs3: Fix OOB read in indx_insert_into_buffer\") by tightening hdr_find_e(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdr_find_split(), not hdr_find_e(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72217", "url": "https://ubuntu.com/security/CVE-2026-72217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing xdr_buf_to_bvec() writes a bio_vec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it. rq_bvec, the array passed by nfsd_vfs_write(), is allocated to exactly rq_maxpages entries with no slack. The OOB store can land in adjacent slab memory; the bv_len and bv_offset fields written there are derived from client-supplied RPC payload sizes. Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72220", "url": "https://ubuntu.com/security/CVE-2026-72220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp->rq_procinfo->pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72221", "url": "https://ubuntu.com/security/CVE-2026-72221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: wait for in-flight TLS handshake callback when cancel loses race When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed. The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result. If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue. If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed. Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed to fire because handshake_complete() invokes svc_tcp_handshake_done() unconditionally once it has set HANDSHAKE_F_REQ_COMPLETED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72222", "url": "https://ubuntu.com/security/CVE-2026-72222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: pin svc_xprt across the asynchronous TLS handshake callback svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of(). Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done. The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry. Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all(). [cel: rewrote commit message to describe the actual change]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72277", "url": "https://ubuntu.com/security/CVE-2026-72277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the simpler thing for now and just reject everything that isn't memory.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72279", "url": "https://ubuntu.com/security/CVE-2026-72279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR KVM currently maps the L1 VNCR into the host stage-1 by relying entirely on the permissions of the guest stage-1. At the same time, it is entirely possible that the backing PFN is read-only (e.g. RO memslot), meaning that the L1 VNCR should use at most a read-only mapping. Cache the writability of the PFN in the VNCR TLB and use it to constrain the resulting fixmap permissions. Promote VNCR permission faults to an SEA in the case where the guest attempts to write to a read-only endpoint. Conveniently, this also plugs a page leak found by Sashiko [*] resulting from the early return for a read-only PFN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72288", "url": "https://ubuntu.com/security/CVE-2026-72288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling Hyunwoo Kim reports some really bad races should the following situation occur: - LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C If the last two race nicely enough, vgic_prune_ap_list() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows. The fix is two-fold: - Before dropping the irq and ap_list locks, take a reference on the irq - Do not try to handle migration of the pending bit: there is no expectation that this state is retained, as per the architecture With that, we're sure that the interrupt is still around, and we safely remove it from the AP list as it has no target at this stage (unless another interrupt fires, but that's another story).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "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-72317", "url": "https://ubuntu.com/security/CVE-2026-72317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: pin upper rpc_clnt across the TLS connect_worker The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt. The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported. Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one. The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72318", "url": "https://ubuntu.com/security/CVE-2026-72318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate DFS referral string offsets parse_dfs_referrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server. Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative max_len is then passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds. Validate each string offset before deriving the string pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72320", "url": "https://ubuntu.com/security/CVE-2026-72320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_lookup: fix catchall element handling with inverted lookups nft_lookup_eval() decides whether a lookup matched (`found`) from the direct set lookup and priv->invert before falling back to the catchall element used by interval sets (e.g. nft_set_rbtree) for the open-ended default range. Since `found` is never recomputed after `ext` is replaced by the catchall lookup, inverted lookups (NFT_LOOKUP_F_INV, \"!= @set\") can wrongly match or wrongly skip the catchall element, producing the wrong verdict. Fold the catchall lookup into `ext` before computing `found`, matching the order already used by nft_objref_map_eval().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72366", "url": "https://ubuntu.com/security/CVE-2026-72366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_create_write_req() to handle async cache object creation netfs_create_write_req() will skip caching if the fscache cookie is disabled, but this is a problem because async cache object creation might not have got far enough yet that has been enabled - thereby causing the call to fscache_begin_write_operation() to be skipped. Fix this by removing the checks on the cookie and delegating this to fscache_begin_write_operation().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72381", "url": "https://ubuntu.com/security/CVE-2026-72381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of fp->owner.name in durable handle owner check Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d (\"ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd\") made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized. BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8 Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72393", "url": "https://ubuntu.com/security/CVE-2026-72393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: don't cache shinfo across skb realloc fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb including the shared info. We can't use the pointer calculated before the call. BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0 Read of size 4 at addr ff110000262edd98 by task swapper/5/0 Call Trace: fbnic_tx_lso.isra.0+0x668/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 Allocated by task 8653: __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xcc/0x6c0 sock_alloc_send_pskb+0x327/0x3f0 __ip_append_data+0x188b/0x47a0 ip_make_skb+0x24a/0x300 udp_sendmsg+0x14d2/0x21e0 Freed by task 0: kfree+0x123/0x5a0 pskb_expand_head+0x36c/0xfa0 fbnic_tx_lso.isra.0+0x500/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 sch_direct_xmit+0x25b/0x1100 The buggy address belongs to the object at ff110000262edc40 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 344 bytes inside of freed 640-byte region [ff110000262edc40, ff110000262ede", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72398", "url": "https://ubuntu.com/security/CVE-2026-72398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: add INIT verification after cookie unpacking In SCTP handshake, the INIT chunk is initially processed by the server and embedded into the cookie carried in INIT-ACK. The client then returns this cookie via COOKIE-ECHO, where the server unpacks it and reconstructs the original INIT chunk. When cookie authentication is enabled, the cookie contents are protected against tampering, so reusing the unpacked INIT without re-verification is safe. However, when cookie authentication is disabled, the reconstructed INIT can no longer be trusted. In this case, the INIT must be explicitly validated after unpacking to avoid processing potentially tampered data. Add sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO processing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook()) when cookie_auth_enable is disabled. On failure, the new association is freed and the packet is discarded. Also tighten cookie validation in sctp_unpack_cookie() by verifying the embedded chunk type is SCTP_CID_INIT before treating it as an INIT chunk. Finally, update sctp_verify_init() to validate parameter bounds using the actual embedded INIT length instead of chunk->chunk_end, since the INIT stored in COOKIE-ECHO may not span the entire chunk buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72399", "url": "https://ubuntu.com/security/CVE-2026-72399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: check the number of BDs needed for xdp_frame The size of xdp_redirect_arr array is ENETC_MAX_SKB_FRAGS. However, the number of fragments contained in xdp_frame may be greater than or equal to ENETC_MAX_SKB_FRAGS, which will cause the access to xdp_redirect_arr to be out of bounds.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72429", "url": "https://ubuntu.com/security/CVE-2026-72429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix type confusion of dst_entry IOAM uses a dummy dst_entry(null_dst) to mark that the destination should not be changed after the transformation. This dst is stored in the IOAM lwt state and may be passed to dst_cache_set_ip6(). However, the IPv6 dst cache path eventually calls rt6_get_cookie(), which treats the dst_entry as part of a struct rt6_info. Since the null_dst was embedded directly as a struct dst_entry in struct ioam6_lwt, this resulted in an invalid cast and rt6_get_cookie() reading fields from the wrong object. In practice, the wrong cookie is not used while dst->obsolete is zero, but rt6_get_cookie() may also access per-cpu value when rt->sernum is zero. In this case, rt->sernum aliases ioam6_lwt::cache::reset_ts, which can become zero, making this a potential invalid pointer access. Fix this by embedding a full struct rt6_info for the dummy IPv6 route and passing its dst member to the dst APIs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72436", "url": "https://ubuntu.com/security/CVE-2026-72436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash types Sashiko pointed out that there are a few lockless RCU readers using test_bit() which is a relaxed atomic operation and provides no memory barrier guarantees. Use test_bit_acquire() instead where the operation may run parallel with add/del/gc, i.e. is not one from the next cases - protected by region lock - in a set destroy phase - in a new/temporary set creation phase", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72451", "url": "https://ubuntu.com/security/CVE-2026-72451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix xfrm state cache insertion race The xfrm input state cache insertion code checks the validity of the state before acquiring the global xfrm_state_lock. Thus it's possible for someone else to kill the state after it passed the validity check, and then the insertion will add the dead state to the cache. Fix this by moving the validity check inside the lock. This entire function is called on the input path, where BH must be off (e.g., the caller of this function xfrm_input acquires its spinlocks without disabling BH). So there is no need to disable BH here or take the RCU read lock. Remove both and replace them with an assertion that trips if BH is accidentally enabled on some future calling path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72472", "url": "https://ubuntu.com/security/CVE-2026-72472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: use nfsi->rwsem to protect traversal of the file lock list Lingfeng identified a bug and suggested two solutions, but both appear to have issues. Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case. Furthermore, after commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk. Regarding the bug fixed by commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), it has been resolved after commit 0460253913e5 (\"NFSv4: nfs4_do_open() is incorrectly triggering state recovery\") because all slots are drained before calling nfs4_do_reclaim, which prevents concurrent stateid changes along this path. Also, nfs_delegation_claim_locks does not cause this concurrency either since when _nfs4_proc_setlk is called with NFS_DELEGATED_STATE, no RPC is sent, so nfs4_lock_done is not called. Therefore, nfs4_lock_delegation_recall from nfs_delegation_claim_locks is the first time the stateid is set.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72473", "url": "https://ubuntu.com/security/CVE-2026-72473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decouple req recycling from RPC completion rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer. Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off. The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry. Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied. Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected. Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released. The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74310", "url": "https://ubuntu.com/security/CVE-2026-74310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/net: complete zerocopy ubufs only once vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74345", "url": "https://ubuntu.com/security/CVE-2026-74345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix endpoint/socket association handling Disassociating a socket from an endpoint via siw_socket_disassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within. This fixes a: BUG: KASAN: slab-use-after-free in siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1053 drivers/infiniband/sw/siw/siw_cm.c:1075) which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74361", "url": "https://ubuntu.com/security/CVE-2026-74361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: fix FDP fdpcidx bounds check The fdpcidx bounds check sets n = NUMFDPC + 1 but used > instead of >=, incorrectly accepting fdp_idx when it equals n (i.e. NUMFDPC + 1).", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74401", "url": "https://ubuntu.com/security/CVE-2026-74401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix add msg handle in send_queue ordered In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as \"before(mh->seq, seq)\" will stop to check for older sequence numbers that are ordered in the tail of \"node->send_queue\". The side effects of not having it correct ordered regarding \"before(mh->seq, seq)\" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74406", "url": "https://ubuntu.com/security/CVE-2026-74406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74428", "url": "https://ubuntu.com/security/CVE-2026-74428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix double unlock in rxrpc_recvmsg() Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74433", "url": "https://ubuntu.com/security/CVE-2026-74433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix UAF in rxgk_issue_challenge() Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74434", "url": "https://ubuntu.com/security/CVE-2026-74434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Don't move a peeked OOB message onto the pending queue rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so only unlink it from recvmsg_oobq and then move it onto pending_oobq or free it when the message is actually consumed.", "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-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-74439", "url": "https://ubuntu.com/security/CVE-2026-74439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clear Present bit before tearing down scalable-mode context entry device_pasid_table_teardown() zeroes the 128-bit scalable-mode context entry with context_clear_entry() while the Present bit is still set. This creates a window where the hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behavior or spurious faults. The context-cache invalidation is issued only after the entry has been zeroed, and intel_pasid_free_table() then frees the PASID directory pages, so the IOMMU can keep walking a stale Present=1 entry that points at freed memory. While x86 provides strong write ordering, the compiler may reorder the two 64-bit writes to the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Commit c1e4f1dccbe9d (\"iommu/vt-d: Clear Present bit before tearing down context entry\") fixed this exact pattern in domain_context_clear_one() and the copied-context path, but device_pasid_table_teardown() was not converted. Align it with the \"Guidance to Software for Invalidations\" in the VT-d spec, Section 6.5.3.3, using the same ownership handshake as the sibling fix: clear only the Present bit, flush it to the IOMMU, perform the context-cache invalidation, and only then zero the rest of the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" } ], "log": [ "", " * noble/linux-riscv-7.0: 7.0.0-38.38.1~24.04.1 -proposed tracker (LP: #2165483)", "", " [ Ubuntu-riscv: 7.0.0-38.38.1 ]", "", " * resolute/linux-riscv: 7.0.0-38.38.1 -proposed tracker (LP: #2165484)", " * resolute: llvm-21-dev build-depends breaks cross-builds (LP: #2165407)", " - [Packaging] Fix cross-builds", " * Zfhmin/Zvfhmin not reported when Zfh/Zvfh are present (LP: #2166547)", " - riscv: report Zfhmin/Zvfhmin when Zfh/Zvfh are present", " [ Ubuntu: 7.0.0-38.38 ]", " * resolute/linux: 7.0.0-38.38 -proposed tracker (LP: #2166443)", " * linux: dtbs_install fails on Resolute builders due to uutils install(1)", " EEXIST race under parallel make (LP: #2166356)", " - SAUCE: [Packaging] Serialise dtbs_install to work around uutils", " install(1) race", " * #510/p sleepable raw tracepoint reject from test_verifier in ubuntu_bpf", " failed with resolute (7.0.0-33.33) generic amd64 (LP: #2165872)", " - SAUCE: Revert \"bpf: Verifier support for sleepable tracepoint programs\"", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189)", " - 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", " - seqlock: Allow UBSAN_ALIGNMENT to fail optimizing", " - KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN", " - crypto: tegra - Don't touch bo refcount in host1x bo pin/unpin", " - xprtrdma: Clear receive-side ownership pointers on release", " - Input: ims-pcu - fix logic error in packet reset", " - fuse: fix writeback array overflow when max_pages is one", " - arm64: tegra: Remove fallback compatible for GPCDMA", " - arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234", " - xfrm: propagate -EINPROGRESS from validate_xmit_xfrm()", " - mtd: mtdswap: remove debugfs stats file on teardown", " - mtd: nand: mtk-ecc: stop on ECC idle timeouts", " - btrfs: fallback to transaction csum tree on a commit root csum miss", " - RDMA/cma: Fix hardware address comparison length in netevent callback", " - RDMA/irdma: Remove redundant legacy_mode checks", " - RDMA/erdma: initialize ret for empty receive WR lists", " - RDMA/mana_ib: initialize err for empty send 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: cfg80211: derive S1G beacon TSF from S1G fields", " - wifi: nl80211: validate nested MBSSID IE blobs", " - wifi: nl80211: constrain MBSSID TX link ID range", " - wifi: cfg80211: validate PMSR measurement type data", " - wifi: cfg80211: reject unsupported PMSR FTM location requests", " - wifi: mac80211: avoid non-S1G AID fallback for S1G assoc", " - ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on", " start/stop", " - ASoC: amd: ps: disable MSI on resume in ACP PCI driver", " - ASoC: amd: ps: fix wrong ACP version string in pci_request_regions()", " - ASoC: amd: ps: replace bitwise OR with logical OR in IRQ return check", " - 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", " - cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq", " - udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()", " - ata: sata_dwc_460ex: use platform_get_irq()", " - ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending", " interrupts", " - accel/ivpu: Fix wrong register read in LNL failure diagnostics", " - ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC", " - drm/i915/gt: use correct selftest config symbol", " - powerpc/85xx: Add fsl,ifc to common device ids", " - powerpc/time: Prepare to stop elapsing in dynticks-idle", " - powerpc/vtime: Initialize starttime at boot for native accounting", " - drm/panthor: Check debugfs GEM lock initialization", " - riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()", " - can: j1939: fix lockless local-destination check", " - drm/xe/wopcm: fix WOPCM size for LNL+", " - drm/i915/wm: clear the plane ddb_y entries on plane disable", " - 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: gadget: fsl-udc: fix dev_printk() device", " - 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", " - SAUCE: Revert \"usb: typec: ucsi: Detect and skip duplicate altmodes from", " buggy firmware\"", " - usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware", " - wifi: mwifiex: fix freeze for 60 seconds caused by request_firmware", " - RISC-V: KVM: Serialize virtual interrupt pending state updates", " - Revert \"drm/amd/display: Add missing kdoc for ALLM parameters\"", " - usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits", " - selftests/bpf: Adjust verifier_map_ptr for the map's excl field", " - selftests/bpf: Keep verifier_map_ptr exercising ops pointer access", " - 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", " - btrfs: fix u32 to s64 type conversion in dirty_metadata_bytes accounting", " - ASoC: sun4i-codec: Set quirks.playback_only for H616 codec", " - 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: fix pointer arithmetic in iwl_add_mcc_to_tas_block_list", " - wifi: iwlwifi: validate payload length in iwl_pnvm_complete_fn", " - wifi: iwlwifi: mvm: fix read in wake packet notification handler", " - usb: atm: ueagle-atm: reject descriptors that confuse probe and", " disconnect", " - drivers/virt: pkvm: Fix end calculation in mmio_guard_ioremap_hook()", " - 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", " - selftests/net: ovpn: fix getaddrinfo memory leak in ovpn_parse_remote()", " - ovpn: use monotonic clock for peer keepalive timeouts", " - regulator: mt6358: use regmap helper to read fixed LDO calibration", " - net: phy: marvell: fix return code", " - netlink: specs: rt-link: convert bridge port flag attributes to u8", " - gtp: parse extension headers before reading inner protocol", " - vhost-net: fix TX stall when vhost owns virtio-net header", " - wifi: mac80211: recalculate TIM when a station enters power save", " - pds_core: reject component parameter in legacy firmware update", " - arm64: Correct value returned by ESR_ELx_FSC_ADDRSZ_nL()", " - amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN", " - soreuseport: Clear sk_reuseport_cb before failure in sk_clone().", " - net: Call net_enable_timestamp() before failure in sk_clone().", " - 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", " - selftests: af_unix: add USER_NS config", " - selftests: openvswitch: add config file", " - selftests: ovpn: add IPV6 and VETH configs", " - selftests: ovpn: increase timeout", " - selftests: drv-net: increase timeout", " - ppp: don't store tx skb in the fastpath", " - ppp: annotate concurrent dev->stats accesses", " - ovl: fix trusted xattr escape prefix matching", " - drm/panel: s6e3ha8: fix unmet dependency on DRM_DISPLAY_HELPER", " - 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", " - drm/xe/i2c: Allow per domain unique id", " - iomap: correct the range of a partial dirty clear", " - drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem", " - net: stmmac: xgmac: fix l4 filter port overwrite on register update", " - 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: annotate data races in ppp_generic", " - hinic: remove unused ethtool RSS user configuration buffers", " - raw: annotate lockless match fields in raw_v4_match()", " - 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", " - octeontx2-pf: tc: fix egress ratelimiting", " - net: ipv6: fix dif and sdif mismatch in raw6_icmp_error", " - ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV", " - ice: fix LAG recipe to profile association", " - ipv6: Change allocation flags to match rcu_read_lock section", " requirements", " - ptp: netc: explicitly clear TMR_OFF during initialization", " - mctp: check register_netdevice_notifier() error in mctp_device_init()", " - net: airoha: fix ETS channel derivation in airoha_tc_setup_qdisc_ets()", " - drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay", " - drm: renesas: rzg2l_mipi_dsi: Move rzg2l_mipi_dsi_set_display_timing()", " - drm/tidss: Fix missing drm_bridge_add() call", " - 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/sysfb: Do not page-align visible size of the framebuffer", " - drm/sysfb: Avoid truncating maximum stride", " - drm/amdgpu/gfx9: Fix Ring and IB test fail after mode2", " - drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT", " - drm/sysfb: Return errno code from drm_sysfb_get_visible_size()", " - drm/displayid: fix Tiled Display Topology ID size", " - drm/nouveau/acr: fix missing nvkm_done() in error path of", " nvkm_acr_oneinit()", " - drm/radeon: fix r100_copy_blit for large BOs", " - drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked binds", " - drm/amdkfd: Use kvcalloc to allocate arrays", " - drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips", " - drm/i915/hdcp: require monotonically increasing seq_num_v", " - drm/amd/amdgpu: disable ASPM on VI if pcie dpm is disabled", " - drm/amd/pm: fix smu14 power limit range calculation", " - drm/gfx10: Program DB_RING_CONTROL", " - drm/virtio: Don't detach GEM from a non-created context", " - drm/panthor: return error on truncated firmware", " - drm/amdgpu: Fix VFCT bus number matching with soft filter", " - drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)", " - drm/amd/display: consolidate DCN vblank/flip handling onto", " vupdate_no_lock", " - drm/amd/display: Force PWM backlight on Lenovo Legion 5 15ARH05", " - drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge", " - drm/amd/display: Fix flip-done timeouts on mode1 reset", " - drm/amd/display: Fix missing DCE check in", " dm_gpureset_toggle_interrupts()", " - drm/v3d: Reach the GMP through the hub registers on V3D 7.x", " - 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: imx219: Fix maximum frame length in lines", " - media: iris: Fix use IRQF_NO_AUTOEN when requesting the IRQ", " - media: marvell-cam: fix missing pci_disable_device() on remove", " - media: nuvoton: npcm-video: fix error handling in npcm_video_init()", " - 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: qcom: camss: Fix RDI streaming for CSID 680", " - media: qcom: camss: Fix RDI streaming for CSID GEN2", " - media: qcom: camss: Fix RDI streaming for CSID GEN3", " - media: rzg2l-cru: Skip ICnMC configuration when ICnSVC is used", " - media: synopsys: hdmirx: Fix HPD lane hold time", " - 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: v4l2-subdev: Fail {enable,disable}_streams and s_streaming nicely", " - media: vb2: use ssize_t for vb2_read/vb2_write", " - media: verisilicon: Export only needed pixels formats", " - media: vidtv: fix reference leak on failed device registration", " - media: vimc: fix reference leak on failed device registration", " - media: vpif_capture: fix OF node reference imbalance", " - ALSA: hda/realtek: Fix speakers on Lunnen Ground 14", " - ALSA: hda: codecs: hdmi: disable keep-alive before audio format change", " - wifi: brcmfmac: set F2 blocksize to 256 for BCM43752", " - wifi: ath11k: fix refcount leak in ath11k_ahb_fw_resources_init()", " - staging: rtl8723bs: fix inverted HT40 secondary channel offset", " - platform/loongarch: laptop: Explicitly reset bl_powered state when", " suspend", " - rust_binder: only print failure if error has source", " - rust: time: fix as_micros_ceil() to round correctly for negative Delta", " - rust: allow `clippy::unwrap_or_default` globally", " - objtool/rust: add one more `noreturn` Rust function for Rust 1.99.0", " - LoongArch: Fix address space mismatch in kexec command line lookup", " - LoongArch: Fix oops during single-step debugging", " - LoongArch: Move jump_label_init() before parse_early_param()", " - LoongArch: Retrieve CPU package ID from PPTT when available", " - x86/boot/compressed: Disable jump tables", " - uio_hv_generic: Bind to FCopy device by default", " - serial: sc16is7xx: implement gpio get_direction() callback", " - selftests: ntsync: correct CONFIG_NTSYNC name", " - tracing: Fix context switch counter truncation", " - 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()", " - mptcp: decrement subflows counter on failed passive join", " - mptcp: only set DATA_FIN when a mapping is present", " - mm/kmemleak: fix checksum computation for per-cpu objects", " - mm/huge_memory: set PG_has_hwpoisoned only after new folio head is", " established", " - ceph: fix refcount leak in ceph_readdir()", " - ceph: fix writeback_count leak in write_folio_nounlock()", " - ASoC: fsl: imx-card: Skip sysclk reset for active DAIs in shutdown", " - ASoC: fsl_sai: Fix spurious BCLK on resume by clearing BYP", " - io_uring/rw: fix missing ERESTARTSYS conversion in read paths", " - iommu/vt-d: Disallow SVA if page walk is not coherent", " - net: stmmac: intel: skip SerDes reconfig when rate is unchanged", " - net: pcs: xpcs: fix SGMII state reading", " - proc: Fix broken error paths for namespace links", " - s390/ptff: Export ptff_function_mask[]", " - smb: client: handle STATUS_STOPPED_ON_SYMLINK responses without a", " symlink target", " - ice: use READ_ONCE() to access cached PHC time", " - ovpn: hold peer before scheduling keepalive work", " - vsock/virtio: collapse receive queue under memory pressure", " - watchdog: s32g_wdt: remove incorrect options in watchdog_info struct", " - drm/amd/pm: fix amdgpu_pm_info power display units", " - drm/amd/pm: make pp_features read-only when scpm is enabled", " - drm/amdgpu/jpeg: fix jpeg_v4_0_3_is_idle detection", " - drm/amdgpu/jpeg: fix jpeg_v5_0_1_is_idle detection", " - drm/amdgpu/soc24: reset dGPU if suspend got aborted", " - drm/amdgpu: fix resource leak on ACP reset timeout", " - drm/amd/pm: fix smu13 power limit range calculation", " - drm/amdgpu: fix check in amdgpu_hmm_invalidate_gfx", " - drm/xe/uapi: Reject coh_none PAT index for CPU_ADDR_MIRROR", " - net: qrtr: ns: Raise node count limit to 512", " - drm/amd/display: Fix DTB DTO updates breaking live pixel rate sources", " - audit: widen ino fields to u64", " - audit: use 'unsigned int' instead of 'unsigned'", " - xfs: don't replace the wrong part of the cow fork", " - netfilter: nf_tables: remove register tracking infrastructure", " - drm: drop lib from header search path.", " - SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlists", " - SUNRPC: Return an error from xdr_buf_to_bvec() on overflow", " - SAUCE: Revert \"mm/sparse-vmemmap: fix vmemmap accounting underflow\"", " - mm/sparse-vmemmap: fix vmemmap accounting underflow", " - mmc: vub300: rename probe error labels", " - net: mana: Optimize irq affinity for low vcpu configs", " - bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c", " - bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()", " - pmdomain: imx93-blk-ctrl: convert to devm_* only", " - rust: allow `suspicious_runtime_symbol_definitions` lint for Rust >=", " 1.98", " - rust: device: avoid trailing ; in printing macros", " - sched_ext: Skip ops.set_weight() for disabled tasks", " - sched_ext: Annotate ksyncs with __rcu in alloc/free_kick_syncs()", " - reset: spacemit: k3: fix USB2 ahb reset", " - wifi: cfg80211: reject empty PMSR peer lists", " - ASoC: amd: acp: Fix linker error with SDCA quirks", " - [Config] Adjust config SND_SOC_ACPI_AMD_SDCA_QUIRKS", " - sched_ext: Enable tick for finite slices on nohz_full", " - Bluetooth: mgmt: Translate HCI reason in Device Disconnected event", " - riscv: Gate FUNCTION_ALIGNMENT_4B on DYNAMIC_FTRACE", " - spi: cadence-quadspi: Fix indirect write timeout when DMA read mode is", " enabled", " - drm/xe: Assign queue name in time for drm_sched_init", " - drm/xe: add WQ_PERCPU to alloc_workqueue users", " - selftests: netconsole: only restore MAC when it changed on resume", " - wifi: ath10k: fix skb leak on incomplete msdu during rx pop", " - wifi: ath12k: Fix low MLO RX throughput on WCN7850", " - iommu/amd: Fix nested domain leak", " - arm_mpam: Fix software reset values of MPAMCFG_PRI", " - arm_mpam: Fix MPAMCFG_MBW_PBM register setting", " - hwmon: Drop unused i2c driver_data", " - hwmon: Use named initializers for arrays of i2c_device_data", " - hwmon: (pmbus/max34440): add support adpm12250", " - hwmon: (pmbus/max34440) block unsupported VIN and IIN limit registers", " - drm/i915/backlight: Remove DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check for", " DPCD backlight", " - selftests/net: Fix tun IPv6 test addresses to avoid 6to4 range", " - geneve: fix hint header definition wrt endianness", " - geneve: ensure the skb is writable before fixing its headers", " - accel: ethosu: Handle U85 internal chaining buffer", " - selftests: drv-net: convert so_txtime to drv-net", " - cifs: prevent readdir from changing file size due to stale directory", " metadata", " - wifi: mt76: fix airoha_npu dependency tracking", " - [Config] Fix config dependencies for MT76_NPU", " - drm/panel: ilitek-ili9882t: fix unmet dependency for", " DRM_PANEL_ILITEK_ILI9882T", " - iomap: fix incorrect did_zero setting in iomap_zero_iter()", " - mpls: Set rt->rt_nhn just before returning from mpls_nh_build_multi().", " - LoongArch: BPF: Zero-extend signed ALU32 div/mod results", " - bnge/bng_re: fix ring ID widths", " - pidfs: make pidfs_ino_lock static", " - LoongArch: BPF: Fix memory leak in bpf_jit_free()", " - drm/exynos: fbdev: Remove offset into screen_buffer", " - drm/tegra: fbdev: Remove offset into framebuffer memory", " - drm/i915/cdclk: Fix up CDCLK_FREQ_DECIMAL without a full PLL re-enable", " - drm/amd/pm: re-enable MC access after PrepareMp1ForUnload on SMU V15", " APUs", " - bitmap: add test_zero_nbits()", " - drm/xe: Add compact-PT and addr mask handling for page reclaim", " - drm/amd/display: Restore periodic detection for DCN35", " - drm/amdgpu: Respect placement requirements in amdgpu_gtt_mgr functions", " - drm/amdkfd: Use exclusive bounds for SVM split alignment checks", " - drm/i915/mtl+: Enable PPS before PLL", " - drm/xe/oa: Fix offset alignment for MERT WHITELIST_OA_MERT_MMIO_TRG", " - drm/xe/nvm: fix writable override for CRI", " - drm/amdgpu: Check for multiplication overflow in checkpoint stack size", " - drm/amdkfd: Guard m->cp_hqd_eop_control setting by", " q->eop_ring_buffer_size", " - drm/amdkfd: free MQD managers on DQM init failures", " - drm/amd/display: set MSA MISC1 bit 6 when using VSC SDP for DCE 11.x", " - drm/amdgpu: add the doorbell index input for suspending userq", " - drm/amdgpu: remove deadlocks from amdgpu_userq_pre_reset", " - drm/amd: Create a device link between APU display and XHCI devices", " - drm/pagemap: Clear driver-provided PFNs from migration PFN array", " - mm: add gpu active/reclaim per-node stat counters (v2)", " - drm/ttm: use gpu mm stats to track gpu memory allocations. (v4)", " - drm/ttm: Fix GPU MM stats during pool shrinking", " - drm/ttm/pool: back up at native page order", " - drm/gpusvm: Zero HMM PFNs before scanning ranges", " - media: mali-c55: Add missing of_reserved_mem_device_release()", " - media: mali-c55: Disable pm_runtime on probe error", " - media: mali-c55: Power-off the peripheral in remove()", " - media: qcom: camss: Fix RDI streaming for CSID 340", " - media: rzv2h-ivc: Wait for frame end in stop_streaming", " - media: ti: vpe: Fix fwnode_handle leak in vip_probe_complete()", " - media: ti: vpe: Fix the error code of devm_request_irq()", " - media: uapi: rkisp: Correct name version enum", " - wifi: mt76: restrict NPU/PPE active checks to MMIO devices", " - LoongArch: Fix build errors due to wrong instructions for 32BIT", " - LoongArch: Increase TASK_STRUCT_OFFSET up to 2040 for 32BIT", " - firmware: stratix10-svc: fix teardown order in remove to prevent race", " - firmware: stratix10-svc: handle NO_RESPONSE in async poll", " - tracing: perf: Fix stale head for perf syscall tracing", " - 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\"", " - selftests: mptcp: userspace_pm: fix undefined variable port", " - m68k: avoid -Wunused-but-set-parameter in clear_user_page()", " - mm/memory-failure: trace: change memory_failure_event to ras subsystem", " - mm/slub: fix lost local objects when bulk remote free batch fills", " - mm/slab: fix a memory leak due to bootstrapping sheaves twice", " - drm/amdgpu: rework userq fence driver alloc/destroy", " - drm/amdgpu: rework userq fence signal processing", " - drm/amdgpu/gfx11: fix EOP interrupt routing for KQ and userq", " - drm/amdgpu/gfx12: fix EOP interrupt routing for KQ and userq", " - drm/amdgpu/mes11: set doorbell offset for suspending userq", " - selftests: drv-net: add missing kconfig for psp.py", " - mm/sparse-vmemmap: pass @pgmap argument to memory deactivation paths", " - mm/sparse-vmemmap: fix DAX vmemmap accounting with optimization", " - selftests: drv-net: cope with slow env in so_txtime.py test", " - selftests: drv-net: so_txtime: relax variance bounds", " - cifs: fix time_last_write stamp placement in setattr/truncate paths", " - cifs: consolidate time_last_write stamp into _cifsFileInfo_put()", " - Upstream stable to v6.18.41, v6.18.42, v6.18.43, v7.1.6, v7.1.7", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68480", " - x86/bugs: Make Safe-RET robust against interrupt injection", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68105", " - drm/amdgpu: Fix kernel panic during driver load failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68109", " - drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68114", " - drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68431", " - ksmbd: validate minimum PDU size for transform requests", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68138", " - net/sched: serialize qdisc_rtab_list against concurrent get/put", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68082", " - libceph: fix two unsafe bare decodes in decode_lockers()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68159", " - libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68163", " - mm/page_vma_mapped: fix device-private PMD handling", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68166", " - userfaultfd: prevent registration of special VMAs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68170", " - mptcp: fix stale skb->sk reference on subflow close", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68177", " - tracing: Delay module ref count for \"enable_event\" trigger", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68191", " - wifi: ath12k: fix NULL pointer dereference in rhash table destroy", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64586", " - wifi: brcmfmac: drain bus_reset work on device removal", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68208", " - media: ti: vpe: Fix the error code of devm_kzalloc() in", " vip_probe_slice()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68224", " - media: mali-c55: Fix possible ERR_PTR in enable_streams", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68237", " - drm/amdgpu/userq: fix indefinite fence wait during GPU reset", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68240", " - drm/gpusvm: publish dpagemap early to avoid device mapping leak on error", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68242", " - drm/i915/gt: Fix NULL deref on sched_engine alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68254", " - drm/i915/vrr: require valid min/max vfreq for VRR", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68436", " - drm/amd/display: use kvzalloc to allocate struct dc", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68447", " - drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68264", " - drm/xe/pt: Reset current_op in xe_pt_update_ops_init()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68265", " - drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68267", " - drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68273", " - drm/amdgpu: Fix context pstate override handling", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68274", " - drm/xe/guc: Fix buffer overflow in steered register list allocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68283", " - tracing: Fix use-after-free freeing trigger private data", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68286", " - drop_monitor: perform u64_stats updates under IRQ-disabled section", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68287", " - drop_monitor: fix size calculations for 64-bit attributes", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68288", " - net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68289", " - tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68291", " - idpf: fix max_vport related crash on allocation error during init", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68303", " - drm/vc4: hvs/v3d: Fix null dereference in unbind", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68312", " - cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain", " paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68316", " - accel: ethosu: Fix element size accounting for cmd stream validation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68322", " - rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68440", " - net: txgbe: fix heap overflow when reading module EEPROM", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68323", " - tipc: serialize udp bearer replicast list updates", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68441", " - net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68337", " - bpf: Reject redirect helpers without a bpf_net_context", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68345", " - arm_mpam: guard MBWU state before adding it to garbage", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68347", " - iommu/amd: Fix IRQ unsafe locking in gdom allocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68375", " - bnxt_en: Handle partially initialized auxiliary devices", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68382", " - drm/xe/guc: Hold device ref until queue teardown completes", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68383", " - drm/xe/guc: Keep scheduler timeline name alive", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68390", " - Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68399", " - bpf: Fix UAF in sock clone early bailouts", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68404", " - wifi: cfg80211: use wiphy work for socket owner autodisconnect", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64581", " - xfrm: fix sk_dst_cache double-free in xfrm_user_policy()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68093", " - KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision", " after hotplug", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68367", " - usb: gadget: f_tcm: synchronize delayed set_alt with teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68164", " - mm/damon/core: disallow overlapping input ranges for damon_set_regions()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68165", " - mm/damon/core: validate ranges in damon_set_regions()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68095", " - fuse-uring: fix race between registration and connection abortion", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68096", " - audit: fix recursive locking deadlock in audit_dupe_exe()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68147", " - fscrypt: Avoid dynamic allocation in fscrypt_get_devices()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68097", " - ksmbd: validate ACE size against SID sub-authorities", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68098", " - ksmbd: bound DACL dedup walk to copied ACEs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68099", " - ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68100", " - ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68173", " - ublk: wait on ublk_dev_ready() instead of ub->completion", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68104", " - drm/amdgpu: invoke pm_genpd_remove() before freeing genpd", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68106", " - drm/amdgpu: fix division by zero with invalid uvd dimensions", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68429", " - drm/dp_mst: Handle torn-down topology gracefully in", " drm_dp_mst_topology_queue_probe()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68107", " - drm/amdgpu/vcn4: avoid rereading IB param length", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68108", " - drm/amdgpu/vce: fix integer overflow in image size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68110", " - drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68111", " - drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68112", " - drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68430", " - drm/amdgpu/gfx8: drop unecessary BUG_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68113", " - drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68246", " - drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68115", " - drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68116", " - vxlan: mdb: Fix source list corruption on a failed replace", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68117", " - tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68118", " - tcp: challenge ACK for non-exact RST in SYN-RECEIVED", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68119", " - tcp: initialize standalone TCP-AO response padding", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68120", " - rtase: Workaround for TX hang caused by hardware packet parsing", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68121", " - pppoe: reload header pointer after dev_hard_header()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68122", " - ovpn: fix peer refcount leak in TCP error paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68123", " - openvswitch: fix GSO userspace truncation underflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68124", " - mctp: serial: handle zero-length frames to prevent rx buffer overflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68125", " - mac802154: llsec: reject frames shorter than the authentication tag", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68126", " - mac802154: hold an interface reference across the scan worker", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68127", " - ila: reload IPv6 header after pskb_may_pull in checksum adjust", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68128", " - ice: reject out-of-range ptype in ice_parser_profile_init", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68129", " - gve: fix Rx queue stall on alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68130", " - ksmbd: defer destroy_previous_session() until after NTLM authentication", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68131", " - rbd: Reset positive result codes to zero in object map update path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68132", " - super: fix emergency thaw deadlock on frozen block devices", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68133", " - ice: fix PTP Call Trace during PTP release", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68134", " - ptp: ptp_s390: Add missing facility check", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68135", " - net: hip04: fix RX buffer leak on build_skb failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68136", " - net: gro: fix double aggregation of flush-marked skbs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68137", " - net/x25: fix use-after-free in x25_kill_by_neigh()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68139", " - net/mlx5e: Use sender devcom for MPV master-up", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68140", " - net/iucv: fix use-after-free of a severed iucv_path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68141", " - net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68142", " - geneve: require CAP_NET_ADMIN in the device netns for changelink", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68143", " - net: slip: serialize receive against buffer reallocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68432", " - vxlan: require CAP_NET_ADMIN in the device netns for changelink", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68144", " - phonet: pep: fix use-after-free in pep_get_sb()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68145", " - iomap: fix out-of-bounds bitmap_set() with zero-length range", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68146", " - ftrace: Add global mutex to serialize trace_parser access", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68148", " - fscrypt: Add missing superblock check in find_or_insert_direct_key()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68149", " - fs: preserve ACL_DONT_CACHE state in forget_cached_acl()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68150", " - fs/super: fix emergency thaw double-unlock of s_umount", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68151", " - binfmt_elf_fdpic: only honour the first PT_INTERP", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68152", " - amt: fix use-after-free in AMT delayed works", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68153", " - libceph: remove debugfs files before client teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68154", " - libceph: reject zero bucket types in crush_decode", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68155", " - libceph: Reject monmaps advertising zero monitors", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68156", " - libceph: refresh auth->authorizer_buf{,_len} after authorizer update", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68157", " - libceph: guard missing CRUSH type name lookup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68158", " - libceph: Fix multiplication overflow in decode_new_up_state_weight()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68433", " - libceph: bound get_version reply decode to front len", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68160", " - ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68161", " - sctp: close UDP tunnel sockets during netns teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68162", " - sctp: avoid auth_enable sysctl UAF during netns teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64564", " - sctp: don't free the ASCONF's own transport in DEL-IP processing", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68168", " - afs: Fix afs_edit_dir_remove() to get, not find, block 0", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68169", " - mptcp: pm: userspace: fix use-after-free in get_local_id", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68172", " - arm64: make huge_ptep_get handled unaligned addresses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68174", " - tracing: Fix union collision of module and refcnt for dynamic events", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68175", " - tracing: Fix resource leak on mmiotrace trace_pipe close", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68176", " - tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68178", " - misc: nsm: pin the module while the device is open", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68179", " - misc: nsm: only unlock nsm_dev on post-lock error paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68180", " - intel_th: fix MSC output device reference leak", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68181", " - mei: bus: access mei_device under device_lock on cleanup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68434", " - serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR", " platforms", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68182", " - comedi: comedi_parport: deal with premature interrupt", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68183", " - firmware: stratix10-svc: fix memory leaks and list corruption bugs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64563", " - rhashtable: clear stale iter->p on table restart", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68184", " - cdrom: fix stack out-of-bounds read in CDROMVOLCTRL", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68186", " - binfmt_misc: set have_execfd only once the interpreter is opened", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68187", " - exec: fix unsigned loop counter wrap in transfer_args_to_stack()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68188", " - Bluetooth: RFCOMM: Fix session UAF in set_termios", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68189", " - Bluetooth: hci_sync: Protect UUID list traversal", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68190", " - staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68192", " - wifi: brcmfmac: make release_scratchbuffers idempotent", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68193", " - wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68194", " - wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68195", " - wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68196", " - wifi: wilc1000: validate assoc response length before subtracting header", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68197", " - wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-", " oper", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68198", " - wifi: ath6kl: fix use-after-free in aggr_reset_state()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68199", " - wifi: ath6kl: fix OOB access from firmware ADDBA window size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68200", " - ALSA: timer: don't re-enter an instance callback that is still running", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68201", " - ALSA: timer: drain a slave's callback before its master detaches it", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68202", " - ALSA: seq: close a re-opened queue timer in the destructor", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68203", " - media: vivid: fix cleanup bugs in vivid_init()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68204", " - media: vivid: check for vb2_is_busy() when toggling caps", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68205", " - media: v4l2-fwnode: Fix subdev owner overwritten in", " v4l2_async_register_subdev_sensor()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68206", " - media: v4l2-ctrls: validate HEVC active reference counts", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68207", " - media: ti: vpe: unwind v4l2 device registration on probe error", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68209", " - media: sun4i-csi: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68210", " - media: stm32: dcmi: unregister notifier on probe failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68211", " - media: stm32-dcmipp: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68212", " - media: saa7134: Fix a possible memory leak in saa7134_video_init1", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68213", " - media: rtl2832_sdr: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68214", " - media: rtl2832: fix use-after-free in rtl2832_remove()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68215", " - media: radio-si476x: Unregister v4l2_device on probe failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68216", " - media: pwc: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68217", " - media: pwc: Drain fill_buf on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68218", " - media: pci: dm1105: Free allocated workqueue", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68219", " - media: nxp: imx8-isi: Fix potential out-of-bounds issues", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68220", " - media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and", " pipe", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68221", " - media: nuvoton: npcm-video: fix memory leaks in probe and remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68222", " - media: msi2500: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68223", " - media: meson: vdec: Fix memory leak in error path of vdec_open", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68225", " - media: i2c: alvium: fix critical pointer access in alvium_ctrl_init", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68226", " - media: cx23885: add ioremap return check and cleanup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68227", " - media: cx231xx: fix devres lifetime", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68228", " - media: chips-media: wave5: Move src_buf Removal to finish_encode", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68229", " - media: cedrus: skip invalid H.264 reference list entries", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68230", " - media: amlogic-c3: Add validations for ae and awb config", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68231", " - media: airspy: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68232", " - drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68445", " - drm/vc4: Prevent shader BO mappings from becoming writable", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68446", " - drm/vmwgfx: Validate vmw_surface_metadata::array_size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68233", " - drm/vc4: Shut down BO cache timer before teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68234", " - drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68235", " - drm/amd/display: dce100: skip non-DP stream encoders for DP MST", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68236", " - drm/amd/display: set new_stream to NULL after release", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68238", " - drm/amdgpu: Release VFCT ACPI table reference", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68239", " - drm/ttm: Account for NULL and handle pages in ttm_pool_backup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68241", " - drm/i915/mst: limit DP MST ESI service loop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68243", " - drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68244", " - drm/i915/gem: Do not leak siblings[] on proto context error", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68245", " - drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68247", " - drm/i915/bios: range check LFP Data Block panel_type2", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68248", " - drm/i915: Return NULL on error in active_instance", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68249", " - drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68250", " - drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68251", " - drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68252", " - drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68253", " - drm/i915/hdcp: check streams[] bounds before overflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68255", " - drm/virtio: bound EDID block reads to the response buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68256", " - drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path", " leaks prev_sink reference", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68257", " - drm/amdkfd: fix 32-bit overflow in CWSR total size calculation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68258", " - drm/amdkfd: Check bounds on CRIU restore queue type and mqd size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68259", " - drm/amdkfd: Check bounds in allocate_event_notification_slot", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68260", " - drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68261", " - drm/imagination: fix error checking of pvr_vm_context_lookup()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68262", " - drm/imagination: Fix user array stride in pvr_set_uobj_array()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68263", " - drm/imagination: Fix double call to drm_sched_entity_fini()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68266", " - drm/xe: Hold a dma-buf reference for imported BOs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68268", " - drm/xe: Return error on non-migratable faults requiring devmem", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68269", " - drm/i915/gem: Add missing nospec on parallel submit slot", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68270", " - drm/sysfb: Avoid possible truncation with calculating visible size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68271", " - drm/nouveau: fix reversed error cleanup order in ucopy functions", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68272", " - drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68275", " - drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68276", " - drm/amdgpu/gfx: fix cleaner shader IB buffer overflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68277", " - drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68437", " - drm/imagination: Fit paired fragment job in the correct CCCB", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68278", " - drm/dp/mst: fix buffer overflows in sideband chunk accumulation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68279", " - drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68280", " - drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68281", " - drm/imagination: Count paired job fence as dependency in prepare_job()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68282", " - drm/rockchip: analogix_dp: Add missing error check for", " platform_get_resource()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68284", " - bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68290", " - rds: tcp: unregister sysctl before tearing down listen socket", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68292", " - ice: prevent tstamp ring allocation for non-PF VSI types", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68293", " - net/mlx5: Fix MCIA register buffer overflow on 32 dword reads", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68294", " - net: qrtr: restrict socket creation to the initial network namespace", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68296", " - net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64575", " - bpf: tcp: fix double sock release on batch realloc", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68297", " - tipc: fix u16 MTU truncation in media and bearer MTU validation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68298", " - drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68299", " - vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68300", " - sctp: auth: verify auth requirement when auth_chunk is NULL", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68301", " - net: hsr: fix memory leak on slave unregistration by removing synced", " VLANs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68302", " - amt: re-read skb header pointers after every pull", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68448", " - ovl: check access to copy_file_range source with src mounter creds", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68304", " - wifi: brcmfmac: fix 802.1X-SHA256 call trace warning", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68306", " - wifi: mt76: mt7996: fix possible NULL-pointer deref in", " mt7996_mcu_sta_bfer_eht()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68307", " - wifi: mt76: mt7925: fix crash in reset link replay", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68308", " - wifi: mt76: mt7996: check pointer returned by", " mt76_connac_get_he_phy_cap()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68439", " - wifi: mt76: mt7925: fix possible NULL-pointer deref in", " mt7925_mcu_bss_he_tlv()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68309", " - wifi: mt76: connac: fix possible NULL-pointer deref in", " mt76_connac_mcu_uni_bss_he_tlv()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68310", " - wifi: mt76: mt7915: guard HE capability lookups", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68311", " - wifi: mt76: mt7925: guard link STA in decap offload", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68313", " - tipc: fix infinite loop in __tipc_nl_compat_dumpit", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64576", " - nexthop: initialize extack in nh_res_bucket_migrate()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64577", " - gtp: check skb_pull_data() return in gtp1u_send_echo_resp()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68314", " - net: mctp i3c: clean up notifier and buses if driver register fails", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68315", " - sctp: validate stream count in sctp_process_strreset_inreq()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68317", " - pds_core: fix auxiliary device add/del races", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68318", " - pds_core: fix use-after-free on workqueue during remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68319", " - pds_core: fix deadlock between reset thread and remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68320", " - sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68321", " - net: txgbe: fix FDIR filter leak on remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68324", " - iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68325", " - iommu/amd: Bound the early ACPI HID map", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68326", " - wifi: mwifiex: bound uAP association event IEs to the event buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68327", " - wan: wanxl: Only reset hardware after BAR mapping", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68328", " - nfp: Check resource mutex allocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64574", " - wifi: mac80211: tear down new links on vif update error path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68329", " - iommu/amd: Wait for completion instead of returning early in", " iommu_completion_wait()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68330", " - net: airoha: Fix DMA direction for NPU mailbox buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68331", " - dpaa2-eth: put MAC endpoint device on disconnect", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68332", " - net: airoha: Fix potential use-after-free in airoha_ppe_deinit()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68333", " - dpaa2-switch: put MAC endpoint device on disconnect", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68334", " - rxrpc: fix io_thread race in rxrpc_wake_up_io_thread()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68335", " - rds: drop incoming messages that cross network namespace boundaries", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68336", " - bonding: fix devconf_all NULL dereference when IPv6 is disabled", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68338", " - net/packet: avoid fanout hook re-registration after unregister", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68339", " - Bluetooth: btusb: validate Realtek vendor event length", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68340", " - hwmon: occ: validate poll response sensor blocks", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68341", " - ovpn: fix use after free in unlock_ovpn()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68342", " - ovpn: avoid putting unrelated P2P peer on socket release", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68343", " - smb: client: validate DFS referral PathConsumed", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68346", " - ALSA: hda: cs35l41: validate and free ACPI mute object", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68348", " - ASoC: tas2781: bound firmware description string parsing", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68450", " - btrfs: free mapping node on duplicate reloc root insert", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68442", " - btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68349", " - wifi: carl9170: fix buffer overflow in rx_stream failover path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68350", " - wifi: carl9170: fix OOB read from off-by-two in TX status handler", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68351", " - wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68352", " - wifi: ath6kl: fix OOB read from firmware IE lengths in connect event", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68353", " - wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68354", " - firewire: net: Fix fragmented datagram reassembly", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68355", " - wifi: ath11k: fix potential buffer underflow in", " ath11k_hal_rx_msdu_list_get()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68356", " - watchdog: airoha: Prevent division by zero when clock frequency is zero", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68357", " - watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68358", " - hwmon: (nzxt-kraken3) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68359", " - hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68443", " - hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68360", " - hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68361", " - hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68362", " - wifi: ath11k: fix NULL pointer dereference in", " ath11k_hal_srng_access_begin", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68363", " - wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware", " request", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68365", " - USB: serial: io_edgeport: cap received transmit credits", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68366", " - usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64583", " - usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before", " teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68368", " - usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68369", " - usb: gadget: printer: fix infinite loop in printer_read()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64584", " - usb: gadget: f_midi: cancel pending IN work before freeing the midi", " object", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68370", " - usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68371", " - usb: musb: omap2430: Do not put borrowed of_node in probe", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68373", " - wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68374", " - usb: core: sysfs: add lock to bos_descriptors_read()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64569", " - mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68376", " - sctp: fix auth_hmacs array size in struct sctp_cookie", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68377", " - net/sched: act_tunnel_key: Defer dst_release to RCU callback", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68378", " - dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68379", " - tcp: fix TIME_WAIT socket reference leak on PSP policy failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68380", " - accel/amdxdna: Fix use-after-free of mm_struct in job scheduler", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64578", " - ksmbd: validate compound request size before reading StructureSize2", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68381", " - ksmbd: pin conn during async oplock break notification", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68384", " - drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68385", " - s390/checksum: Fix csum_partial() without vector facility", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68386", " - bpf, sockmap: Reject unhashed UDP sockets on sockmap update", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68387", " - can: raw: add locking for raw flags bitfield", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68388", " - smb/client: handle overlapping allocated ranges in fallocate", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68389", " - Bluetooth: hci_qca: Clear memdump state on invalid dump size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68391", " - Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68392", " - Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68393", " - Bluetooth: hci_sync: extend conn_hash lookup critical sections", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68394", " - Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64573", " - Bluetooth: qca: fix NVM tag length underflow in TLV parser", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68449", " - ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-", " scanning", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68395", " - ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is", " registered", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68396", " - scsi: core: wake eh reliably when using scsi_schedule_eh", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68397", " - net/iucv: take a reference on the socket found in afiucv_hs_rcv()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64572", " - ipv4: fib: free fib_alias with kfree_rcu() on insert error path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68398", " - ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68400", " - firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset", " calculation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68401", " - firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68402", " - wifi: cfg80211: bound element ID read when checking non-inheritance", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68403", " - wifi: brcmfmac: initialize SDIO data work before cleanup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68405", " - wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68406", " - wifi: cfg80211: validate PMSR FTM preamble range", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68407", " - wifi: nl80211: free RNR data on MBSSID mismatch", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68408", " - wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64571", " - wifi: p54: validate RX frame length in p54_rx_eeprom_readback()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68409", " - wifi: mac80211: defer link RX stats percpu free to RCU", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68410", " - wifi: libertas: fix memory leak in helper_firmware_cb()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64570", " - wifi: mac80211: fix fils_discovery double free on alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64568", " - wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68411", " - wifi: mac80211_hwsim: clamp virtio RX length before skb_put", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68412", " - wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68413", " - wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68414", " - wifi: cfg80211: cancel sched scan results work on unregister", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64579", " - xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64580", " - xfrm6: clear dst.dev on error to avoid double netdev_put in", " xfrm6_fill_dst()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64566", " - xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68415", " - xfrm: clear mode callbacks after failed mode setup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68416", " - mtd: fix double free and WARN_ON in add_mtd_device() error paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68417", " - RDMA/siw: publish QP after initialization", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68418", " - RDMA/irdma: Prevent user-triggered null deref on QP create", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68419", " - RDMA/irdma: Prevent rereg_mr for non-mem regions", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68420", " - xfrm: reject optional IPTFS templates in outbound policies", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68421", " - sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68444", " - firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68422", " - btrfs: fix root leak if its reloc root is unexpected in", " merge_reloc_roots()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64567", " - btrfs: reject free space cache with more entries than pages", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68425", " - IB/mad: Drop unmatched RMPP responses before reassembly", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68426", " - xfrm: fix stale skb->prev after async crypto steals a GSO segment", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64565", " - Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68427", " - gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68428", " - KVM: x86/mmu: Fix use-after-free on vendor module reload", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64562", " - KVM: nVMX: Hide shadow VMCS right after VMCLEAR", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64561", " - KVM: x86: Check for invalid/obsolete root *after* making MMU pages", " available", " * resolute: llvm-21-dev build-depends breaks cross-builds (LP: #2165407)", " - [Packaging] Fix cross-builds", " * Resolute Stable Update v6.18.40, v7.1.5 bugs (LP: #2165040)", " - accel/amdxdna: Allow forcing IOVA-based DMA via module parameter", " - SAUCE: bpf: Add missing NULL argument to zap_page_range_single", " - accel/amdxdna: Return ERR_PTR on dma_alloc_noncoherent failure", " - accel/amdxdna: Fix memory leak in amdxdna_iommu_alloc()", " * [SRU][HPE] Take Intel platform into account for old microcode checks", " (LP: #2161748)", " - x86/microcode: Refactor platform ID enumeration into a helper", " - x86/cpu: Add platform ID to CPU info structure", " - x86/cpu: Add platform ID to CPU matching structure", " - x86/microcode: Add platform mask to Intel microcode \"old\" list", " - x86/microcode: Do not access MSR_IA32_PLATFORM_ID when running as a", " guest", " * ice: E810 interface fails to initialize (ice_init_hw failed: -5) during", " NVM read (LP: #2163508)", " - ice: acquire NVM lock around each flash read", " * WWAN modem unresponsive after freeze on Dell systems with DW5826e", " (LP: #2163214)", " - platform/x86: dell-dw5826e: Add reset driver for DW5826e", " - platform/x86: dell-dw5826e: fix ACPI _DSM function index and bitmask", " usage", " - [Config] Add CONFIG_DELL_DW5826E_RESET=m", " * amdgpu panel self-refresh on dual-gpu laptops causes complete built-in", " panel freeze and severe system instability (LP: #2162904)", " - SAUCE: drm/amdgpu: Do not enter PSR if multiple displays are active", " * linux 7.0: dw9719 VCM never binds, disabling all IPU3 cameras (regression,", " fixed upstream) (LP: #2162045)", " - media: dw9719: Add back the I²C device id table", " * Fix TAS2783 SoundWire amp resume timeout >5s (LP: #2164967)", " - soundwire: Add a helper function to wait for device initialisation", " - ASoC: tas2783: Use new SoundWire enumeration helper", " - soundwire: Move wait for initialisation helper to header", " - ASoC: codecs: tas2783-sdw: Propagate regcache_sync() errors", " - ASoC: tas2783-sdw: drop stale regcache on uninitialized re-attach", " * Linux, Ubuntu, 24.04, System hangs for about 10 seconds when unplug", " external monitor cable on non TBT dock (LP: #2160082)", " - SAUCE: drm/i915/tc: Revert forced DP-alt connected workaround", " * Speakers not detected on HP systems with TI TAS2783 SoundWire amps", " (LP: #2164504)", " - ASoC: sdw_utils: Add missed component_name strings for TI amps", " * [TWL][Desktop] intel_dmc_wait_fw_load() merge to Ubuntu next release", " (LP: #2156316)", " - SAUCE: drm/i915/dmc: fix assert_dmc_loaded WARN during async firmware", " load", " * 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", " * Ethernet adapter unusable after suspend/resume on Advantech systems with", " Intel I226-V (LP: #2163375)", " - igc: fix netdev not re-attached after resume if interface is down", " * ice: fix stale -EBUSY on resume of Intel E810 (LP: #2162803)", " - ice: wait for reset completion in ice_resume()", " * idxd: crash-kernel NULL-pointer Oops in `destroy_workqueue()` breaks kdump", " on Intel DSA/IAA systems (LP: #2163062)", " - SAUCE: dmaengine: idxd: Do not call destroy_workqueue with null idxd->wq", " - SAUCE: dmaengine: idxd: fix duplicate memory frees on initialization", " error path.", " * [HP][ZBook Power 16 G11] Laptop freezed after upgrading the BIOS", " (LP: #2132119)", " - PCI/ASPM: Avoid L0s for Realtek RTS525A", " * Fix noise of audio output on more Dell QCx1255 models after reboot", " (LP: #2163293)", " - ALSA: hda/realtek - Add quirk for Dell Pro QC1255", " * Fix no audio input/output device on Dell WCL Slate platform with", " CirrusLogic audio solution (LP: #2160200)", " - ASoC: SDCA: fix the register to ctl value conversion for Q7.8 format", " - ASoC: SOF: ipc4-control: Use local copy of IPC message for sending", " * Fix no audio output and mute hotkey not working on HP ZBook 8 G2a", " (LP: #2158858)", " - ALSA: hda/realtek: Add inverted LED quirk for HP ZBook 8 G2a", " * Dock ethernet stops working after Thunderbolt dock unplug on Dell systems", " (LP: #2162704)", " - usb: core: port: Deattach Type-C connector on component unbind", " * USB-C alt mode dropped with false firmware bug warning on Dell systems", " (LP: #2162695)", " - Revert \"usb: typec: ucsi: Detect and skip duplicate altmodes from buggy", " firmware\"", " - Revert \"usb: typec: ucsi: Add duplicate detection to nvidia registration", " path\"", " - Revert \"usb: typec: ucsi: yoga_c630: Remove redundant duplicate altmode", " handling\"", " - usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware", " - usb: typec: ucsi: Add duplicate detection to nvidia registration path", " - usb: typec: ucsi: yoga_c630: Remove redundant duplicate altmode handling", " * Resolute update: upstream stable patchset 2026-08-20 (LP: #2164666)", " - crypto: algif_skcipher - force synchronous processing", " - crypto: sun4i-ss - Remove insecure and unused rng_alg", " - [Config] Remove unused CRYPTO_DEV_SUN4I_SS_PRNG", " - media: uvcvideo: Fix deadlock if uvc_status_stop is called from", " async_ctrl.work", " - bpf: Clear delta when clearing reg id for non-{add,sub} ops", " - selftests/bpf: Add tests for delta tracking when src_reg == dst_reg", " - selftests/bpf: Add tests for stale delta leaking through id reassignment", " - ALSA: hda/realtek: Add quirk for TongFang X6xx45xU", " - ALSA: hda: conexant: Remove mic bias threshold override", " - ALSA: hda: Fix cached processing coefficient verbs", " - ALSA: hda/realtek: Fix speakers on Legion Pro 7 16ARX8H with codec SSID", " 17aa:38a7", " - media: uvcvideo: Use hw timestaming if the clock buffer is full", " - media: uvcvideo: Avoid partial metadata buffers", " - media: uvcvideo: Fix buffer sequence in frame gaps", " - media: uvcvideo: Fix dev_sof filtering in hw timestamp", " - media: uvcvideo: Do not add clock samples with small sof delta", " - media: uvcvideo: Relax the constrains for interpolating the hw clock", " - 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: max310x: implement gpio_chip::get_direction()", " - serial: 8250_omap: clear rx_running on zero-length DMA completes", " - rxrpc: rxrpc_verify_data ensure rx_dec_buffer alloc", " - rxrpc: Fix socket notification race", " - rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)", " - rxrpc: Fix potential infinite loop in rxrpc_recvmsg()", " - rxrpc: Fix rxrpc_rotate_tx_rotate() to check there's something to rotate", " - rxrpc: Fix oob challenge leak in cleanup after notification failure", " - rxrpc: Fix ACKALL packet handling", " - rxrpc: Fix the reception of a reply packet before data transmission", " - rxrpc: Fix leak of connection from OOB challenge", " - afs: fix NULL pointer dereference in afs_get_tree()", " - afs: handle CB.InitCallBackState3 requests without a server record", " - afs: Fix uncancelled rxrpc OOB message handler", " - fbcon: fix NULL pointer dereference for a console without vc_data", " - fbcon: Use correct type for vc_resize() return value", " - openrisc: mm: Fix section mismatch between map_page and __set_fixmap", " - clocksource/drivers/sun5i: Handle error returns from", " devm_reset_control_get_optional_exclusive()", " - accel/amdxdna: Fix leak when pinning ubuf pages", " - drm/rockchip: dw_dp: Switch to drmm_kzalloc()", " - drm/rockchip: dw_dp: Fix null-ptr-deref in dw_dp_remove()", " - drm/rockchip: Test for imported buffers with drm_gem_is_imported()", " - drm/tidss: Drop extra drm_mode_config_reset() call", " - drm/gpusvm: Reject VMAs with VM_IO or VM_PFNMAP when creating SVM ranges", " - drm/gpuvm: Do not prepare NULL objects", " - 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", " - selftests/bpf: Fix off-by-one in bpf_cpumask_populate related selftest", " - dt-bindings: timer: Remove sifive,fine-ctr-bits property", " - drm/amd/pm: remove trailing semicolon from AMDGPU_PM_POLICY_ATTR macro", " - selftests/bpf: Use local type for flow_offload_tuple_rhash in", " xdp_flowtable", " - selftests/bpf: Use local type for bpf_fou_encap in test_tunnel_kern", " - Documentation: proc: fix section numbering in table of contents", " - arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Cobra", " - arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S", " - arm64: dts: qcom: ipq5424: Fix USB simple_bus_reg warnings", " - arm64: dts: qcom: sc8180x: Fix phy simple_bus_reg warning", " - 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: fix wrong pci_get_drvdata type in AER handlers", " - wifi: rtw88: fix wrong pci_get_drvdata type in AER handlers", " - wifi: rtw89: Correct data type for scan index to avoid infinite loop", " - wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA", " buffer", " - wifi: rtw89: add bounds check on firmware mac_id in link lookup", " - kconfig: fix potential NULL pointer dereference in conf_askvalue", " - soc: xilinx: Shutdown and free rx mailbox channel", " - pinctrl: mediatek: eint: Drop base from mtk_eint_chip_write_mask()", " - wifi: ath9k: fix OOB access from firmware tx status queue ID", " - ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint", " - Documentation/rv: Replace stale website link", " - 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", " - memory: tegra: Wire up system sleep PM ops", " - crypto: qat - fix heartbeat error injection", " - lib/vsprintf: Fix to check field_width and precision", " - dts: spacemit: set console baud rate on bpif3", " - pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path", " - dt-bindings: vendor-prefixes: Add Displaytech Ltd.", " - drm/gpuvm: take refcount on DRM device", " - drm/panel: Clean up S6E3HA2 config dependencies and fill help text", " - ARM: dts: rockchip: Add #{address,size}-cells to Chromium-based", " /firmware", " - arm64: dts: rockchip: Add #{address,size}-cells to Chromium-based", " /firmware", " - arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc", " - arm64: dts: imx8x-colibri: Correct SODIMM PAD settings", " - Revert \"arm64: dts: imx8mm-kontron: Add support for reading SD_VSEL", " signal\"", " - Revert \"arm64: dts: imx8mp-kontron: Add support for reading SD_VSEL", " signal\"", " - drm: renesas: rz-du: mipi_dsi: Fix return path on error", " - alarmtimer: Remove stale return description from alarm_handle_timer()", " - OPP: Fix race between OPP addition and lookup", " - crypto: ccp - Reverse the cleanup order in psp_dev_destroy()", " - crypto: ccp - Fix snp_filter_reserved_mem_regions() off-by-one", " - 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", " - ARM: multi_v7_defconfig: Correct QCOM_RPMH and QCOM_RPMHPD", " - nilfs2: fix backing_dev_info reference leak", " - media: qcom: camss: vfe: fix PIX subdev naming on VFE lite", " - media: iris: scale MMCX power domain on SM8250", " - media: venus: scale MMCX power domain on SM8250", " - iommu/amd: Fix a stale comment about which legacy mode is user visible", " - soc: mediatek: mtk-mmsys: Restore MT8167 routing masks lost during merge", " - bpf: fix crash in bpf_[set|remove]_dentry_xattr for negative dentries", " - uaccess: fix ignored_trailing logic in copy_struct_to_user()", " - arm64: dts: mediatek: mt8192-asurada: Move PCIe DMA bounce buffer to", " host", " - rust: alloc: fix `Vec::extend_with` SAFETY comment", " - clk: scmi: Fix clock rate rounding", " - arm64: dts: qcom: kodiak: Fix ICE reg size", " - arm64: dts: qcom: sm8450: Fix ICE reg size", " - drm/hisilicon/hibmc: add updating link cap in DP detect()", " - drm/hisilicon/hibmc: fix no showing when no connectors connected", " - drm/hisilicon/hibmc: move display contrl config to hibmc_probe()", " - 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()", " - scsi: hisi_sas: Add slave_destroy interface for v3 hw", " - 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)", " - IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier", " - RDMA/hns: Fix arithmetic overflow in calc_hem_config()", " - RDMA/mlx5: Fix UMR XLT cleanup on ODP populate failure", " - RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference", " - RDMA/hns: Initialize seqfile before creating file", " - drm/syncobj: Fix memory leak in drm_syncobj_find_fence()", " - selftests/bpf: Reject unsupported -k option in vmtest.sh", " - selftests/bpf: Fix test for refinement of single-value tnum", " - iommu/arm-smmu-qcom: Fix fastrpc compatible string in ACTLR client match", " table", " - selftests/mm: Fix resv_sz when parsing arm64 signal frame", " - firmware: arm_ffa: Honor partition info descriptor size", " - arm64: dts: imx8dxl-evk: Remove unnecessary PCIe EP properties", " - arm64: dts: imx8qxp-mek: Remove unnecessary PCIe EP vpcie-supply", " - arm64: dts: imx95-19x19-evk: Fix PCIe EP vpcie-supply", " - media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()", " - media: atomisp: gc2235: fix UAF and memory leak", " - staging: media: atomisp: fix loop shadowing in ia_css_stream_destroy()", " - riscv: dts: spacemit: set console baud rate on Milk-V Jupiter", " - firmware: smccc: Fix Arm SMCCC SOC_ID name call", " - firmware: arm_scmi: Read sensor config as 32-bit value", " - sysfs: clamp show() return value in sysfs_kf_read()", " - bitops: use common function parameter names", " - regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions", " - tools/nolibc: getopt: Fix potential out of bounds access", " - nilfs2: Fix return in nilfs_mkdir", " - net/sched: sch_drr: annotate data-races around cl->deficit", " - media: rockchip: rga: fix too small buffer size", " - firmware: arm_scmi: Fix OOB in scmi_power_name_get()", " - arm64: dts: qcom: lemans: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: monaco: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sc7180: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: kodiak: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8550: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8750: Add power-domain and iface clk for ice node", " - tracing: Bound synthetic-field strings with seq_buf", " - arm64: dts: qcom: lemans: Add eDP ref clock for eDP PHYs", " - writeback: drop now-unnecessary rcu_barrier() in", " cgroup_writeback_umount()", " - kernfs: fix suspicious RCU usage in kernfs_put()", " - 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", " - Revert \"treewide: Fix probing of devices in DT overlays\"", " - of: dynamic: Fix overlayed devices not probing because of fw_devlink", " - crypto: eip93 - fix reset ring register definition", " - cpufreq: Documentation: fix sampling_down_factor range", " - cpufreq: conservative: Simplify frequency limit handling", " - pwm: imx27: Fix variable truncation in .apply()", " - RDMA/mana_ib: Use ib_get_eth_speed for reporting port speed", " - bus: sunxi-rsb: Always check register address validity", " - pinctrl: spacemit: fix NULL check in spacemit_pin_set_config", " - 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/hns: Fix log flood after cmd_mbox failure", " - RDMA/counter: Fix incorrect port index in rdma_counter_init() error", " cleanup", " - pinctrl: meson: amlogic-a4: fix gpio output glitch", " - PM: sleep: Use complete() in device_pm_sleep_init()", " - 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", " - driver core: Fix missing jiffies conversion in", " deferred_probe_extend_timeout()", " - driver core: Guard deferred probe timeout extension with", " delayed_work_pending()", " - mtd: spi-nor: debugfs: Fix the flags list", " - mtd: spi-nor: Drop duplicate Kconfig dependency", " - ALSA: xen-front: Reset event channel state on stream clear", " - ALSA: xen-front: Connect event channel after stream prepare", " - ALSA: seq: oss: Fix UAF at handling events with embedded SysEx data", " - ALSA: seq: midi: Serialize output teardown with event_input", " - selftests: Fix Makefile target for nsfs", " - pinctrl: nuvoton: ma35d1: fix MFP register offset and pin table", " - pinctrl: cs42l43: Fix leaked pm reference on error path", " - pinctrl: cs42l43: Fix polarity on debounce", " - init/initramfs_test: wait_for_initramfs() before running", " - nvmet-tcp: fix page fragment cache leak in error path", " - nvmet-tcp: check return value of nvmet_tcp_set_queue_sock", " - nvme-pci: fix out-of-bounds access in nvme_setup_descriptor_pools", " - 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", " - iommu/amd: Fix premature break in init_iommu_one()", " - rtla/actions: Restore continue flag in actions_perform()", " - 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", " - bpftool: Fix typo in struct_ops map FD generation for light skeleton", " - libbpf: Fix UAF in strset__add_str()", " - ARM: tegra: Add #{address,size}-cells to Chromium-based /firmware", " - arm64: tegra: Add #{address,size}-cells to Chromium-based /firmware", " - 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", " - crypto: inside-secure/eip93 - Add check for devm_request_threaded_irq", " - crypto: tegra - Fix dma_free_coherent size error", " - crypto: tegra - Return ENOMEM when input buffer allocation fails for ccm", " - sched/deadline: Reject debugfs dl_server writes for offline CPUs", " - drm/msm/dp: fix HPD state status bit shift value", " - drm/msm/dp: Fix the ISR_* enum values", " - EDAC/igen6: Fix call trace due to missing release()", " - EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in", " skx_get_dimm_info", " - arm64: dts: st: Fix SAI addresses on stm32mp251", " - RDMA/umem: Add ib_umem_is_contiguous() stub for", " !CONFIG_INFINIBAND_USER_MEM", " - RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe", " - RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path", " - Revert \"media: venus: hfi_platform: Correct supported codecs for sc7280\"", " - 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", " - amba: use generic driver_override infrastructure", " - cdx: use generic driver_override infrastructure", " - Drivers: hv: vmbus: use generic driver_override infrastructure", " - rpmsg: use generic driver_override infrastructure", " - raid1: fix nr_pending leak in REQ_ATOMIC bad-block error path", " - bpf: fix BPF_PROG_QUERY OOB write and cgroup backward compat", " - selftests/bpf: add verification for BPF_PROG_QUERY attr size boundaries", " - libbpf: Skip hash computation when loader generation failed", " - libbpf: Skip endianness swap when loader generation failed", " - ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data", " writeback", " - spi: atmel: fix DMA channel and bounce buffer leaks", " - ASoC: rsnd: Fix RSND_SOC_MASK width to single nibble", " - NFSD: Fix delegation reference leak in nfsd4_revoke_states", " - ARM: imx3: Fix CCM node reference leak", " - HID: wiimote: Fix table layout and whitespace errors", " - wifi: ath12k: fix incorrect HT/VHT/HE/EHT MCS reporting in monitor mode", " - wifi: ath12k: fix NULL deref in change_sta_links for unready link", " - ata: libata: Fix ata_exec_internal()", " - ARM: imx31: Fix IIM mapping leak in revision check", " - x86/cpu: Keep the PROCESSOR_SELECT menu together", " - nvdimm/btt: Handle preemption in BTT lane acquisition", " - scsi: Revert \"scsi: Fix sas_user_scan() to handle wildcard and multi-", " channel scans\"", " - bpf: Reject exclusive maps as inner maps in map-in-map", " - libbpf: Reject non-exclusive metadata maps in the signed loader", " - libbpf: Skip initial_value override on signed loaders", " - libbpf: Skip max_entries override on signed loaders", " - 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", " - driver core: Use system_percpu_wq instead of system_wq", " - bpf: Reject exclusive maps for bpf_map_elem iterators", " - tick/sched: Fix TOCTOU in nohz idle time fetch", " - lib/test_meminit: use && for bools", " - riscv: dts: sophgo: sg2044: use hex for CPU unit address", " - riscv: dts: sophgo: sg2042: use hex for CPU unit address", " - configfs_lookup(): don't leave ->s_dentry dangling on failure", " - lockdep/selftests: Restore migrate_disable() state on PREEMPT_RT", " - lockdep/selftests: Restore sched_rt_mutex state on PREEMPT_RT", " - ext4: fix fast commit wait/wake bit mapping on 64-bit", " - drm/amdgpu: set sub_block_index for mca ras sub-blocks", " - bpftool: Use libbpf error code for flow dissector query", " - vhost: fix vhost_get_avail_idx for a non empty ring", " - iommu/vt-d: Fix RB-tree corruption in probe error path", " - perf/x86/amd/core: Always use the NMI latency mitigation", " - perf/x86/intel/uncore: Fix discovery unit lookup for multi-die systems", " - perf/x86/amd/uncore: Use Node ID to identify DF and UMC domains", " - xfrm: fix NAT-related field inheritance in SA migration", " - cxl/fwctl: Fix __fortify_panic", " - drm/amdkfd: always resume_all after suspend_all", " - of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array()", " fails", " - ocfs2: rebase copied fsdlm LVB pointers in locking_state", " - lib: kunit_iov_iter: repeatedly call alloc_pages_bulk()", " - 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: 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", " - netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock", " - ALSA: usb-audio: qcom: Initialize offload control return value", " - x86/cpu: Remove obsolete aperfmperf_get_khz() declaration", " - netfilter: conntrack: revert ct extension genid infrastructure", " - netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper", " is pptp", " - RDMA/hfi1: Open-code rvt_set_ibdev_name()", " - IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()", " - ALSA: hda: fix Kconfig dependency of HD Audio PCI", " - RDMA/irdma: Fix OOB read during CQ MR registration", " - RDMA/irdma: Initialize iwmr->access during MR registration", " - arm64: dts: imx8mp-kontron: Reduce EERAM SPI clock frequency", " - arm64: dts: imx95: Correct PCIe outbound address space configuration", " - arm64: dts: lx2162a-clearfog: use rev2 SoC dtsi", " - arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio codec as", " well", " - arm64: dts: imx8mp-kontron: Fix GPIO for display power switch", " - bpf: Clear rb node linkage when freeing bpf_rb_root", " - bpf: Check tail zero of bpf_map_info", " - 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: cpu_ops: Change return value type of cpu_is_stopped() to bool", " - riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe", " - ALSA: seq: Clear variable event pointer on read", " - bpf: Fix NMI/tracepoint re-entry deadlock on lru locks", " - kunit:tool: Don't write to stdout when it should be disabled", " - powerpc/8xx: implement get_direction() in cpm1", " - bpf: Fix NULL pointer dereference in bpf_task_from_vpid()", " - ACPI: IPMI: Fix message kref handling on dead device", " - cpufreq: Documentation: fix conservative governor freq_step description", " - thermal: testing: reject missing command arguments", " - btrfs: don't force DIO writes to be serialized", " - IB/mlx5: Don't take the rereg_mr fallback without a new translation", " - IB/mlx5: Properly support implicit ODP rereg_mr", " - IB/mlx5: Remove unused mkc bits in mlx5r_umr_update_mr_page_shift()", " - IB/mlx5: Pull the pdn out of the depths of the umr machinery", " - IB/mlx5: Don't mangle the mr->pd inside the rereg callback", " - spi: ep93xx: fix double-free of zeropage on DMA setup failure", " - ASoC: amd: acp-sdw-legacy: Bound DAI link iteration", " - ASoC: amd: acp-sdw-sof: Bound DAI link iteration", " - firmware_loader: Fix recursive lock in device_cache_fw_images()", " - configfs: fix lockless traversals of ->s_children", " - watchdog: unregister PM notifier on watchdog unregister", " - pinctrl: qcom: Fix resolving register base address from device node", " - 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", " - ARM: configs: Drop duplicated CONFIG_EXT4_FS", " - wifi: mt76: mt7925: clean up DMA on probe failure", " - wifi: mt76: use kfree_rcu for offchannel link in mt76_put_vif_phy_link", " - wifi: mt76: mt7996: add missing max_remain_on_channel_duration", " - wifi: mt76: mt7925: fix stale pointer comparisons in change_vif_links", " - wifi: mt76: mt7925: keep TX BA state in the primary WCID", " - wifi: mt76: mt792x: skip MLD header rewrite for 802.3 encap TX", " - wifi: mt76: mt7925: validate skb length in testmode query", " - wifi: mt76: mt7996: Fix possible token leak in mt7996_tx_prepare_skb()", " - wifi: mt76: mt7996: Fix possible NULL pointer dereference in", " mt7996_mac_write_txwi_80211()", " - wifi: mt76: mt7996: fix reading zeroed info->control.flags after", " mt76_tx_status_skb_add()", " - wifi: mt76: mt7996: limit work in set_bitrate_mask", " - 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", " - wifi: mt76: mt7925: fix potential tx_retries underflow", " - wifi: mt76: mt7996: fix potential tx_retries underflow", " - btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()", " - ALSA: aloop: Drop superfluous break", " - gpio: mt7621: fix interrupt banks mapping on gpio chips", " - wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is", " reported", " - fbdev: sm501fb: Fix buffer errors in OF binding code", " - vfs: add FS_USERNS_DELEGATABLE flag and set it for NFS", " - hwmon: (it87) Clamp negative values to zero in set_fan()", " - btrfs: zoned: don't account data relocation space-info in statfs free", " space", " - Revert \"btrfs: fix the file offset calculation inside", " btrfs_decompress_buf2page()\"", " - btrfs: zoned: always set max_active_zones for zoned devices", " - btrfs: annotate lockless read of defrag_bytes in should_nocow()", " - btrfs: fix deadlock cloning inline extent when using flushoncommit", " - igc: skip RX timestamp header for frame preemption verification", " - ASoC: sma1307: Fix uevent string leaks in fault worker", " - IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified", " - NFSD: Handle layout stid in nfsd4_drop_revoked_stid()", " - 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", " - virtio: rtc: tear down old virtqueues before restore", " - virtio_console: read size from config space during device init", " - vduse: Requeue failed read to send_list head", " - tools/virtio: check mmap return value in vringh_test", " - vdpa/octeon_ep: Fix PF->VF mailbox data address calculation", " - vdpa/octeon_ep: fix IRQ-to-ring mapping in interrupt handler", " - ASoC: cs35l56: Fix missing calls to wm_adsp2_remove()", " - ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend fails", " - ext4: fix ERR_PTR(0) in ext4_mkdir()", " - tools: missed broadcast_neigh if_link uapi header", " - netlink: specs: rt-link: missed broadcast-neigh", " - bonding: 3ad: add lacp_strict configuration knob", " - bonding: 3ad: fix carrier when no usable slaves", " - 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()", " - vfio/qat: fix f_pos race in qat_vf_resume_write()", " - bpf: Tighten cgroup storage cookie checks for prog arrays", " - pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag", " - pinctrl: airoha: an7581: add missed gpio32 pin group", " - pinctrl: airoha: an7581: fix misprint in gpio19 pinconf", " - arm64: dts: allwinner: a523: Add missing GPIO interrupt", " - ASoC: cs35l56: Fix possible uninitialized value in", " cs35l56_spi_system_reset()", " - s390/process: Fix kernel thread function pointer type", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for", " non-serdev device", " - Bluetooth: eir: Fix stack OOB write when prepending the Flags AD", " - Bluetooth: hci_event: fix simultaneous discovery stuck in FINDING", " - Bluetooth: hci_core: Fix UAF in hci_unregister_dev()", " - Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path", " - Bluetooth: hci: validate codec capability element length", " - Bluetooth: vhci: validate devcoredump state before side effects", " - fs: efs: remove unneeded debug prints", " - RDMA/mlx5: Remove DCT restrack tracking", " - 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: SOF: Intel: hda-sdw-bpt: select SND_SOF_SOF_HDA_SDW_BPT properly", " - 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: dsa: qca8k: fix led devicename when using external mdio bus", " - 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", " - net: pfcp: allocate per-cpu tstats for PFCP netdevs", " - 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: Unregister cxl_acpi in cxl_test_init() error path", " - 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", " - ALSA: usb-audio: qcom: Guard sideband endpoint removal", " - ALSA: seq: Fix kernel heap address leak in bounce_error_event()", " - spi: xilinx: use FIFO occupancy register to determine buffer size", " - iommu: Avoid copying the user array twice in the full-array copy helper", " - 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", " - virtio_net: do not allow tunnel csum offload for non GSO packets", " - net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net/sched: sch_dualpi2: 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", " - net: watchdog: fix refcount tracking races", " - net: ethernet: mtk_wed: fix loading WO firmware for MT7986", " - net/sched: sch_dualpi2: Add missing module alias", " - bpf: Run generic devmap egress prog on private skb", " - net/mlx5: Check max_macs devlink param value against max capability", " - bpf: Fix setting retval to -EPERM for cgroup hooks not returning errno", " - octeontx2-af: npc: Fix size of entry2cntr_map", " - net: ethernet: mtk_wed: debugfs: correct index in wed_amsdu_show()", " - net: wwan: t7xx: check skb_clone in control TX", " - 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", " - net: bcmgenet: Use weighted round-robin TX DMA arbitration", " - net: airoha: Fix register index for Tx-fwd counter configuration", " - net: airoha: Fix debugfs new-tuple display for IPv4 ROUTE entries", " - kcm: use WRITE_ONCE() when changing lower socket callbacks", " - ALSA: seq: oss: Serialize readq reset state with q->lock", " - ALSA: seq: avoid stale FIFO cells during resize", " - 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: Fix typo in verify_umulti_link_info", " - selftests/bpf: Initialize operation name before use", " - bpf: Fix bpf_get/setsockopt to tos for ipv4-mapped ipv6 socket", " - udf: fix nls leak on udf_fill_super() failure", " - bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()", " - net: remove addr_len argument of recvmsg() handlers", " - sockmap: Fix use-after-free in udp_bpf_recvmsg()", " - 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", " - tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)", " - net: airoha: Fix always-true condition in PPE1 queue reservation loop", " - net: ethernet: oa_tc6: Remove FCS size in RX frame", " - ionic: Fix check in ionic_get_link_ext_stats", " - RDMA/bnxt_re: Free SRQ toggle page after firmware teardown", " - RDMA/bnxt_re: Avoid displaying the kernel pointer", " - RDMA/bnxt_re: Fail DBR related page allocation UAPIs if the feature is", " disabled", " - ksmbd: fix use-after-free in same_client_has_lease()", " - mfd: rsmu: Fix page register setup", " - mfd: cs42l43: Sanity check firmware size", " - ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write", " - 9p: avoid returning ERR_PTR(0) from mkdir operations", " - eventpoll: rename ep_remove_safe() back to ep_remove()", " - eventpoll: expand top-of-file overview / locking doc", " - eventpoll: rename attach_epitem() to ep_attach_file()", " - 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", " - i3c: master: svc: Fix missed IBI after false SLVSTART on NPCM845", " - staging: nvec: fix use-after-free in nvec_rx_completed()", " - perf debuginfo: Fix libdw API contract violations", " - coresight: cti: Fix DT filter signals silently ignored", " - soundwire: don't program SDW_SCP_BUSCLOCK_SCALE on a unattached", " Peripheral", " - soundwire: fix bug in sdw_add_element_group_count found by syzkaller", " - coresight: ete: Always save state on power down", " - 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", " - perf sched: Add missing mmap2 handler in timehist", " - PCI: loongson: Do not ignore downstream devices on external bridges", " - rust: alloc: fix assert in `Vec::reserve` doc test", " - bus: mhi: ep: Fix potential deadlock in mhi_ep_reset_worker()", " - coresight: fix missing error code when trace ID is invalid", " - clk: qcom: cmnpll: Account for reference clock divider", " - phy: phy-can-transceiver: Check driver match and driver data against", " NULL", " - perf pmu: Skip test on Arm64 when #slots is zero", " - clk: at91: sam9x7: Fix gmac_gclk clock definition", " - soundwire: intel_ace2x: release bpt_stream when close it", " - coresight: Fix source not disabled on idr_alloc_u32 failure", " - mailbox: mpfs: fix check for syscon presence in mpfs_mbox_inbox_isr()", " - mailbox: mtk-adsp: fix UAF during device teardown", " - PCI: dwc: Fix signedness bug in fault injection test code", " - perf build-id: Fix off-by-one bug when printing kernel/module build-id", " - 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", " - perf test amd ibs: Fix incorrect kernel version check", " - gpib: Fix inappropriate ioctl error return", " - char: tlclk: fix use-after-free in tlclk_cleanup()", " - gpib: fix double decrement of descriptor_busy in command_ioctl()", " - clk: renesas: rzg2l: Rename iterator in for_each_mod_clock() to avoid", " shadowing", " - powerpc tools perf: Initialize error code in auxtrace_record_init", " function", " - PCI: qcom: Disable ASPM L0s for SA8775P", " - perf header: Sanity check HEADER_EVENT_DESC attr.size before swap", " - 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", " - drm/amd/display: Add missing kdoc for ALLM parameters", " - thunderbolt: debugfs: Fix margining error counter buffer leak", " - dmaengine: imx-sdma: Refine spba bus searching in probe", " - dt-bindings: dma: nvidia,tegra186-gpc-dma: Make reset optional", " - perf: Fix off-by-one stack buffer overflow in kallsyms__parse()", " - perf annotate: Fix crashes on empty annotate windows", " - perf tools: Guard test_bit from out-of-bounds sample CPU", " - perf sched: Fix thread reference leak in latency_switch_event", " - perf tools: Add bounds check to cpu__get_node()", " - perf sched: Cap max_cpu at MAX_CPUS in timehist sample processing", " - perf sched: Fix register_pid() overflow, strcpy, and BUG_ON", " - perf mmap: Guard cpu__get_node() return in aio_bind()", " - perf stat: Bounds-check CPU index in topology aggregation callbacks", " - perf c2c: Bounds-check CPU and node IDs before bitmap and array access", " - perf c2c: Bounds-check CPU IDs in setup_nodes() topology loop", " - perf sched: Clean up idle_threads entry on init failure", " - perf sched: Use thread__put() in free_idle_threads()", " - perf sched: Replace BUG_ON and add NULL checks in replay event helpers", " - perf mmap: Fix NULL deref in aio cleanup on alloc failure", " - perf stat: Introduce perf_env__get_cpu_topology() to guard NULL env->cpu", " - perf c2c: Fix use-after-free in he__get_c2c_hists() error path", " - perf timechart: Fix cpu2y() OOB read on untrusted CPU index", " - perf tools: Fix int16_t truncation of max_cpu_num in set_max_cpu_num()", " - dt-bindings: clock: qcom: Add X1P42100 camera clock controller", " - clk: qcom: camcc-x1e80100: Add support for camera QDSS debug clocks", " - mshv: add bounds check on vp_index in mshv_intercept_isr()", " - dmaengine: qcom: gpi: set DMA_PRIVATE capability", " - dmaengine: Fix possible use after free", " - dmaengine: dma-axi-dmac: Properly free struct axi_dmac_desc", " - dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor", " - clk: qcom: a53: Corrected frequency multiplier for 1152MHz", " - sunrpc: Fix error handling in rpc_sysfs_xprt_switch_add_xprt_store()", " - pNFS/filelayout: fix cheking if a layout is striped", " - 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", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in", " pg_get_mirror_count_write", " - PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro", " - pwm: rzg2l-gpt: Add missing newlines to dev_err_probe() messages", " - PCI: meson: Propagate devm_add_action_or_reset() failure", " - PCI: meson: Add missing remove callback", " - fs/ntfs3: resize log->one_page_buf when adopting on-disk page size", " - platform/x86/intel/vsec: Decouple add/link helpers from PCI", " - platform/x86/intel/vsec: Switch exported helpers from pci_dev to device", " - platform/x86/intel/vsec: Return real error codes from registration path", " - platform/x86/intel/vsec: Restore BAR fallback for header walk", " - perf tools: Fix get_max_num() size_t underflow on empty sysfs file", " - perf tools: Use scnprintf() in cpu_map__snprint() to prevent overflow", " - perf tools: Use perf_env__get_cpu_topology() in machine__resolve()", " - PCI: rcar-host: Remove unused LIST_HEAD(res)", " - perf sched: Bounds-check prio before test_bit() in timehist", " - perf sched: Fix idle-hist callchain display using wrong rb_first variant", " - perf bpf: Use scnprintf() in snprintf_hex() and", " synthesize_bpf_prog_name()", " - perf hists: Fix snprintf() in hists__scnprintf_title() UID filter path", " - xprtrdma: Fix ep kref imbalance on ADDR_CHANGE", " - xprtrdma: Initialize re_id before removal registration", " - xprtrdma: Check frwr_wp_create() during connect", " - xprtrdma: Document and assert reply-handler invariants", " - xprtrdma: Resize reply buffers before reposting receives", " - xprtrdma: Sanitize the reply credit grant after parsing", " - xprtrdma: Repost Receive buffers for malformed replies", " - xprtrdma: Return sendctx slot after Send preparation failure", " - perf s390: Fix TEXTREL in Python extension by compiling as PIC", " - perf cs-etm: Queue context packets for frontend", " - perf pmu: Fix pmu_id() heap underwrite on empty identifier file", " - perf pmu: Fix perf_pmu__parse_scale/unit() OOB access on empty sysfs", " file", " - tools lib api: Fix missing null termination in filename__read_int/ull()", " - perf symbols: Fix signed overflow in sysfs__read_build_id() size check", " - perf symbols: Bounds-check .gnu_debuglink section data", " - perf intel-pt: Fix snprintf size tracking bug in insn decoder", " - perf tools: Fix thread__set_comm_from_proc() on empty comm file", " - perf hwmon: Fix off-by-one null termination on sysfs reads", " - perf hwmon: Use scnprintf() in hwmon_pmu__for_each_event()", " - perf hwmon: Fix parse_hwmon_filename() strlcpy buffer overflow", " - perf symbols: Bounds-check descsz in sysfs__read_build_id() GNU fallback", " - perf hwmon: Guard label read against empty or failed reads", " - perf tools: Use snprintf() in dso__read_running_kernel_build_id()", " - tools lib api: Fix filename__write_int() writing uninitialized stack", " data", " - tools lib api: Fix mount_overload() snprintf truncation and toupper", " range", " - perf bpf: Add NULL check for btf__type_by_id() in", " synthesize_bpf_prog_name()", " - perf bpf: Fix map data leak in bpf_metadata_create() on alloc failure", " - perf bpf: Fix metadata leak in perf_env__add_bpf_info() on duplicate", " insert", " - perf symbols: Add bounds checks to elf_read_build_id() note iteration", " - perf symbols: Add bounds checks to read_build_id() note iteration in", " minimal build", " - dt-bindings: phy: sc8280xp-qmp-pcie: Disallow bifurcation register on", " Purwa", " - PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()", " - PCI: mediatek: Use actual physical address instead of virt_to_phys()", " - phy: freescale: phy-fsl-imx8qm-lvds-phy: Fix missing", " pm_runtime_disable() on probe error path", " - PCI: dwc: Avoid dwc_pcie_rasdes_debugfs_deinit() NULL dereference when", " no RAS DES capability", " - Revert \"PCI/MSI: Unmap MSI-X region on error\"", " - apparmor: fix shadowing of plabel that prevents cache from being updated", " - apparmor: fix race in unix socket mediation when peer_path is used", " - apparmor: fix refcount leak when updating the sk_ctx", " - security/apparmor/apparmorfs.c: conditionally compile", " get_loaddata_common_ref()", " - apparmor: check label build before no_new_privs test", " - apparmor: aa_label_alloc use aa_label_free on alloc failure", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [41/57]: apparmor-next 7.1:", " apparmor: fix rawdata_f_data implicit flex array\"", " - apparmor: fix rawdata_f_data implicit flex array", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [38/57]: apparmor-next 7.1:", " apparmor: grab ns lock and refresh when looking up changehat child", " profiles\"", " - apparmor: grab ns lock and refresh when looking up changehat child", " profiles", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [44/57]: apparmor-next 7.1:", " apparmor: fix potential UAF in aa_replace_profiles\"", " - apparmor: fix potential UAF in aa_replace_profiles", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor: fix NULL pointer dereference in", " unpack_pdb\"", " - apparmor: fix NULL pointer dereference in unpack_pdb", " - apparmor: remove or add symlinks to rawdata according to export_binary", " - apparmor: Fix return in ns_mkdir_op", " - apparmor: fail policy unpack on accept2 allocation failure", " - apparmor: aa_getprocattr free procattr leak on format failure", " - apparmor: put secmark label after secid lookup", " - apparmor: don't audit files pointing to aa_null.dentry", " - apparmor: fix uninitialised pointer passed to", " audit_log_untrustedstring()", " - i3c: mipi-i3c-hci: Preserve RUN bit when aborting DMA ring", " - i3c: master: Make hot-join workqueue freezable to block hot-join during", " suspend", " - i3c: master: Move rstdaa error suppression", " - i3c: master: Consolidate Hot-Join DAA work in the core", " - i3c: master: Ensure Hot-Join operations are stopped on shutdown", " - i3c: master: Defer new-device registration out of DAA caller context", " - i3c: master: Prevent reuse of dynamic address on device add failure", " - apparmor: fix label can not be immediately before a declaration", " - accel/ivpu: fix HWS command queue leak on registration failure", " - sparc: led: avoid trimming a newline from empty writes", " - perf symbols: Fix bswap copy-paste error for 32-bit ELF p_filesz", " - perf symbols: Validate p_filesz before use in filename__read_build_id()", " - perf symbols: Break infinite loop on zero-filled notes in", " sysfs__read_build_id()", " - perf tools: Add O_CLOEXEC to open() calls in DSO and ELF code", " - perf tools: Fix uninitialized pathname on uncompressed fallback in", " filename__decompress()", " - perf dso: Fix heap overflow in dso__get_filename() on decompressed path", " - perf dso: Set error code when open() fails on uncompressed fallback path", " - perf tools: Use snprintf() for root_dir path construction", " - perf hwmon: Fix fd check to accept fd 0 in hwmon_pmu__describe_items()", " - perf sched: Replace (void*)1 sentinel with proper runtime allocation", " - perf bpf: Validate func_info_rec_size and sub_id in", " synthesize_bpf_prog_name()", " - perf bpf: Reject oversized BPF metadata events that truncate header.size", " - perf bpf: Bounds-check array offsets in bpil_offs_to_addr()", " - perf cs-etm: Reject CPU IDs that would overflow signed comparison", " - gpio: mlxbf3: fail probe if gpiochip registration fails", " - drm/i915: clear CRTC color blob pointers after dropping refs", " - drm/xe: Fix wa_oob codegen recipe for external module builds", " - spi: dw: fix wrong BAUDR setting after resume", " - i3c: master: Update dev_nack_retry_count under maintenance lock", " - i3c: master: Add missing runtime PM get in dev_nack_retry_count_store()", " - ALSA: usb-audio: qcom: Free sideband sg_table objects", " - xfrm: annotate data-races around xfrm_policy_count[] and", " xfrm_policy_default[]", " - xfrm: validate selector family and prefixlen during match", " - perf machine: Use snprintf() for guestmount path construction", " - perf cs-etm: Validate num_cpu before metadata allocation", " - perf cs-etm: Require full global header in auxtrace_info size check", " - perf cs-etm: Bounds-check CPU in cs_etm__get_queue()", " - perf bpf: Validate array presence before casting BPF prog info pointers", " - perf dso: Set standard errno on decompression failure", " - ASoC: tlv320aic3x: restrict CLKDIV bypass Q values in dual-rate mode", " - drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free", " - drm/amd/display: Fix mem_type change detection for async flips", " - drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm", " - drm/amdgpu: initialize irq.lock spinlock earlier", " - 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", " - ALSA: usb-audio: qcom: reject stream disable with no active interface", " - ALSA: usb-audio: qcom: clear opened when stream enable fails", " - 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()", " - dpaa2-switch: fix VLAN upper check not rejecting bridge join", " - devlink: Fix parent ref leak in devl_rate_node_create()", " - devlink: Fix parent ref leak on tc-bw failure", " - net: airoha: fix foe_check_time allocation size", " - net: macb: add TX stall timeout callback to recover from lost TSTART", " write", " - flow_dissector: check device type before reading ETH_ADDRS", " - selftests: vlan_bridge_binding: Fix flaky operational state check", " - 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: Restore initial state on failed device_rename() in", " cfg802154_switch_netns()", " - ieee802154: Avoid calling WARN_ON() on -ENOMEM in", " cfg802154_switch_netns()", " - ieee802154: Remove WARN_ON() in cfg802154_pernet_exit()", " - ieee802154: fix kernel-infoleak in dgram_recvmsg()", " - mac802154: Prevent overwrite return code in", " mac802154_perform_association()", " - md/raid1: honor REQ_NOWAIT when waiting for behind writes", " - md/raid1: free r1_bio when REQ_NOWAIT is set and read would block on", " retry", " - netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()", " - netfilter: ipset: make sure gc is properly stopped", " - netfilter: nft_payload: reject offsets exceeding 65535 bytes", " - netfilter: nft_meta_bridge: add validate callback for get operations", " - netfilter: nft_flow_offload: zero device address for non-ether case", " - netfilter: nf_reject: skip iphdr options when looking for icmp header", " - netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak", " - mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()", " - irqchip/crossbar: Fix parent domain resource leak", " - alloc_tag: fix use-after-free in /proc/allocinfo after module unload", " - selftests/mm: restore default nr_hugepages value via exit trap in", " charge_reserved_hugetlb.sh", " - selftests/mm: restore default nr_hugepages value via exit trap in", " hugetlb_reparenting_test.sh", " - selftests/mm: fix hugetlb pathname construction in", " hugetlb_reparenting_test.sh", " - selftests/mm: fix cgroup task placement and drop memory.current checks", " in hugetlb_reparenting_test.sh", " - selftests/mm: size tmpfs according to PMD page size in", " split_huge_page_test", " - selftests/mm: free dynamically allocated PMD-sized buffers in", " split_huge_page_test", " - selftest/mm: register existing mapping with userfaultfd in hugetlb-", " mremap", " - selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap", " - selftests/mm: skip uffd-stress test when nr_pages_per_cpu is zero", " - 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", " - net: emac: Fix NULL pointer dereference in emac_probe", " - net/sched: act_ct: fix nf_connlabels leak on two error paths", " - net: airoha: Fix skb->priority underflow in airoha_dev_select_queue()", " - ipv6: ndisc: fix NULL deref in accept_untracked_na()", " - dpaa2-switch: do not accept VLAN uppers while bridged", " - 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", " - bpftool: Fix vmlinux BTF leak in cgroup commands", " - bpf: zero-initialize the fib lookup flow struct", " - bpf: Fix effective prog array index with BPF_F_PREORDER", " - power: sequencing: fix ABBA deadlock in pwrseq_device_unregister()", " - gpiolib: initialize return value in gpiochip_set_multiple()", " - 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()", " - ice: call netif_keep_dst() once when entering switchdev mode", " - rtc: isl1208: Balance enable_irq_wake() with disable_irq_wake() on", " cleanup", " - 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", " - i40e: Fix i40e_debug() to use struct i40e_hw argument", " - rtc: msc313: fix NULL deref in shared IRQ handler at probe", " - ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().", " - eth: bnxt: rename ring_err_stats -> ring_drv_stats", " - eth: bnxt: improve the timing of stats", " - ipv4: fib: Don't ignore error route in local/main tables.", " - md/raid5: use stripe state snapshot in break_stripe_batch_list()", " - md/raid5: avoid R5_Overlap races while breaking stripe batches", " - 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", " - gpio: davinci: fix IRQ domain leak on devm_kzalloc failure", " - 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: do not acquire dev->tx_global_lock in netdev_watchdog_up()", " - net: dsa: sja1105: round up PTP perout pin duration", " - veth: fix NAPI leak in XDP enable error path", " - net: usb: lan78xx: restore VLAN and hash filters after link up", " - 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", " - ipv6: fix state corruption during proxy_ndp sysctl restart", " - ipv6: fix missing notification for ignore_routes_with_linkdown", " - eth: fbnic: fix ordering of heartbeat vs ownership", " - thermal: testing: zone: Flush work items during cleanup", " - ACPI: processor_idle: Mark LPI enter functions as __cpuidle", " - 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: dsa: realtek: fix memory leak in rtl8366rb_setup_led()", " - net: phy: realtek: Clear MDIO_AN_10GBT_CTRL_ADV10G bit", " - octeontx2-af: Validate NIX maximum LFs correctly", " - 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", " - LoongArch: Move struct kimage forward declaration before use", " - LoongArch: BPF: Fix outdated tail call comments", " - LoongArch: BPF: Fix off-by-one error in tail call", " - ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count", " - net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync", " - dt-bindings: net: renesas,ether: Drop example \"ethernet-phy-", " ieee802.3-c22\" fallback", " - selftests: tls: size splice_short pipe by page size", " - 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", " - ALSA: FCP: Fix NULL pointer dereference in interface lookup", " - tracing: probes: fix typo in a log message", " - spi: sh-msiof: abort transfers when reset times out", " - ACPI: RIMT: Only defer the IOMMU configuration in init stage", " - riscv: Fix 32-bit call_on_irq_stack() frame pointer ABI", " - gpio: mvebu: fail probe if gpiochip registration fails", " - gpio: htc-egpio: use managed gpiochip registration", " - net: pse-pd: scope pse_control regulator handle to kref lifetime", " - seg6: validate SRH length before reading fixed fields", " - qede: fix out-of-bounds check for cqe->len_list[]", " - sctp: fix SCTP_RESET_STREAMS stream list length limit", " - MIPS: DEC: Ensure RTC platform device deregistration upon failure", " - MIPS: mm: Add check for highmem before removing memory block", " - ASoC: codecs: lpass-va-macro: Fix LPASS Codec Version for SC7280", " - hwmon: adm1275: Prevent reading uninitialized stack", " - hwmon: (pmbus) Fix passing events to regulator core", " - hwmon: (aspeed-g6-pwm-tach) Guard fan RPM calculation against divide-by-", " zero", " - ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump", " - usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()", " - net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy", " - net: libwx: fix VMDQ mask for 1-queue mode", " - 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", " - drm/panthor: Fix potential invalid pointer deref in", " group_process_tiler_oom()", " - drm/panthor: Don't overrule pending immediate ticks in", " sched_resume_tick()", " - drm/panthor: Fix a leak when a group is evicted before the tiler OOM is", " serviced", " - drm/panthor: Interrupt group start/resumption if group_bind_locked()", " fails", " - tracing/eprobes: Allow use of BTF names to dereference pointers", " - tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg", " - tracing/events: Fix to check the simple_tsk_fn creation", " - tracing: eprobe: read the complete FILTER_PTR_STRING pointer", " - tracing/fprobe: Fix NULL pointer dereference in fprobe_fgraph_entry()", " - tracing/probes: Make the $ prefix mandatory for comm access", " - irqchip/gic-v3-its: Fix OF node reference leak", " - irqchip/ts4800: Fix missing chained handler cleanup on remove", " - sctp: fix addr_wq_timer race in sctp_free_addr_wq()", " - virtio_net: disable cb when NAPI is busy-polled", " - cxgb4: Fix decode strings dump for T6 adapters", " - selftests: drv-net: tso: don't touch dangerous feature bits", " - 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: dualpi2: clear stale classification on filter miss", " - 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: Fix double netfs initialisation in afs_root_iget()", " - afs: use kvfree() to free memory allocated by kvcalloc()", " - afs: Remove erroneous seq |= 1 in volume lookup loop", " - afs: Fix bulk lookup malfunction due to change in dir_emit() API", " - afs: Fix misplaced inc of net->cells_outstanding", " - afs: Fix reinitialisation of the inode, in particular ->lock_work", " - afs: Fix callback service message parsers to pass through -EAGAIN", " - afs: Fix missing NULL pointer check in afs_break_some_callbacks()", " - afs: Fix vllist leak", " - afs: Fix lack of locking around modifications of net->cells_dyn_ino", " - afs: Fix premature cell exposure through /afs", " - 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", " - ovl: fix comment about locking order", " - iomap: guard io_size EOF trim against concurrent truncate underflow", " - netfs: Fix writethrough to use collection offload", " - netfs: Fix writeback error handling", " - netfs: Fix folio state after ENOMEM whilst under writeback iteration", " - drm/xe/pt: Fix NULL pointer dereference in xe_pt_zap_ptes_entry()", " - drm/xe/userptr: Hold notifier_lock for write on inject test path", " - drm/xe/hw_engine: Fix double-free of managed BO in error path", " - drm/xe/pf: Don't attempt to process FAST_REQ or EVENT relays", " - x86/uprobes: Keep shadow stack in sync for emulated CALLs", " - uprobes/x86: Use proper mm_struct in __in_uprobe_trampoline", " - cifs: Fix missing credit release on failure in cifs_issue_read()", " - ata: sata_gemini: unwind clocks on IDE pinctrl errors", " - ata: libata-scsi: limit simulated SCSI command copy to response length", " - 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: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()", " - HID: bpf: Fix hid_bpf_get_data() range check", " - selftests/hid: Load only requested struct_ops maps", " - selftests/hid: Cover hid_bpf_get_data() size overflow", " - arm64/sysreg: Fix BWE field encoding in ID_AA64DFR2_EL1", " - net: usb: net1080: validate packet_len before pad-byte access in", " rx_fixup", " - netfilter: xt_u32: reject invalid shift counts", " - netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()", " - netfilter: nft_set_rbtree: get command skips end element with open", " interval", " - netfilter: xt_connmark: reject invalid shift parameters", " - net/mlx5: LAG, MPESW, Fix missing complete() on devcom error", " - net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation", " - net/mlx5e: Fix HV VHCA stats agent registration race", " - net/mlx5e: Fix publication race for priv->channel_stats[]", " - net: microchip: vcap: fix races on the shared Super VCAP block", " - net: qualcomm: rmnet: validate MAP frame length before ingress parsing", " - net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload", " - 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: sco: Fix a race condition in sco_sock_timeout()", " - Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length", " - Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()", " - Bluetooth: L2CAP: fix tx ident leak for commands without a response", " - ring-buffer: Fix event length with forced 8-byte alignment", " - accel/amdxdna: Use unsigned long for nr_pages in amdxdna_hmm_register()", " - net/tls: Consume empty data records in tls_sw_read_sock()", " - net: usb: lan78xx: disable VLAN filter in promiscuous mode", " - gpio: dwapb: reduce allocation to single kzalloc", " - gpio: dwapb: Defer clock gating until noirq", " - tracing: Make tracepoint_printk static as not exported", " - accel/amdxdna: Fix potential amdxdna_umap lifetime race", " - drm/v3d: Reject invalid indirect BO handle in indirect CSD setup", " - net: mdio: select REGMAP_MMIO instead of depending on it", " - net/sched: cake: reject overhead values that underflow length", " - octeontx2-pf: check DMAC extraction support before filtering", " - perf/x86/amd/core: Avoid enabling BRS from the SVM reload path", " - gpio: mvebu: free generic chips on unbind", " - ipv4: igmp: annotate data-races around im->users", " - ipv4: igmp: annotate data-races around timer-related fields", " - ipv4: igmp: Fix potential memory leaks in igmp_mod_timer() and", " igmp_stop_timer()", " - ipvs: pass parsed transport offset to state handlers", " - ipvs: use parsed transport offset in TCP state lookup", " - s390/zcrypt: Remove the empty file", " - SUNRPC: release lower rpc_clnt if killed waiting for XPRT_LOCKED", " - 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", " - drm/xe: remove duplicate include", " - smb: client: fix overflow in passthrough ioctl bounds check", " - idpf: add padding to PTP virtchnl structures", " - 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", " - octeontx2-pf: clear stale mailbox IRQ state before request_irq()", " - octeontx2-vf: clear stale mailbox IRQ state before request_irq()", " - arm64: fpsimd: Fix type mismatch in sve_{save,load}_state()", " - arm64: dts: s32g3: Fix SWT8 watchdog address", " - ARM: dts: imx6ul-var-som: fix warning for non-existent dc-supply", " property", " - arm64: dts: qcom: sdm630: describe adsp_mem region properly", " - arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Ringneck", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix ADC sampling times", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move divergent mecio1 ADC", " channels to board files", " - arm64: dts: ti: k3-am62a7-sk: Add bootph-all tag to vqmmc", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Enable internal ADC reference", " - arm64: dts: imx8ulp-evk: Correct Type-C int GPIO flags", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix GPIO names typo", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move gpio-line-names to board", " files", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix expander gpio line typo", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move expander gpio-line-names to", " board files", " - LoongArch: KVM: Validate irqchip index in irqfd routing", " - 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()", " - powerpc/pseries/Kconfig: Enable CONFIG_VPA_PMU to be used with KVM", " - KVM: s390: pci: Fix GISC refcount leak on AIF enable failure", " - KVM: s390: pci: Fix handling of AIF enable without AISB", " - KVM: SEV: Do not allow intra-host migration/mirroring of SNP VMs", " - KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs", " - KVM: x86: Nullify irqfd->producer if updating IRTE for bypass fails", " - KVM: nVMX: Put vmcs12 pages if nested VM-Enter fails due to invalid", " guest state", " - KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers", " - KVM: arm64: nv: Drop bogus WARN for write to ZCR_EL2", " - KVM: arm64: nv: Write ESR_EL2 for injected nested SError exceptions", " - KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()", " - 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: efifb: fix memory leak in efifb_probe()", " - 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: Check runtime resume during probe", " - ASoC: mediatek: mt8192: Release reserved memory on cleanup", " - ASoC: mediatek: mt8183: Check runtime resume during probe", " - 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: nft_set_pipapo: don't leak bad clone into future transaction", " - 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", " - selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()", " - selinux: fix incorrect execmem checks on overlayfs", " - 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/brs: Fix kernel address leakage", " - perf/x86/amd/lbr: Fix kernel address leakage", " - cpufreq: schedutil: Fix uncleared need_freq_update on the .adjust_perf()", " path", " - cpufreq: intel_pstate: Set non-turbo capacity to HWP_GUARANTEED_PERF()", " - 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: retrieve ethhdr after potential skb realloc on RX", " - 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: ensure minimal ethernet header on TX", " - 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: clean untagged VLAN on netdev registration failure", " - batman-adv: frag: fix primary_if leak on failed linearization", " - batman-adv: mcast: avoid OOB read of num_dests header", " - 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", " - lockd: Plug nlm_file leak when nlm_do_fopen() fails", " - lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure", " - 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()", " - mm/mm_init: fix pageblock migratetype for ZONE_DEVICE compound pages", " - power: supply: cpcap-battery: Fix missing nvmem_device_put() causing", " reference leak", " - power: supply: max17042: fix OF node reference imbalance", " - mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch", " - mm/memory_hotplug: fix incorrect altmap passing in error path", " - 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: bound NTFS_DE view.data_off in", " UpdateRecordData{Root,Allocation}", " - ntfs3: cap RESTART_TABLE free-chain walker at rt->used", " - ntfs3: fix out-of-bounds read in decompress_lznt", " - landlock: Fix LANDLOCK_SCOPE_SIGNAL bypass on the SIGIO path", " - power: supply: charger-manager: fix refcount leak in is_full_charged()", " - selftests/landlock: Test SCOPE_SIGNAL on the SIGIO/fowner pgid path", " - 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", " - 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()", " - proc: only bump parent nlink when registering directories", " - fs/proc: fix KPF_KSM reported for all anonymous pages", " - powerpc/dt_cpu_ftrs: Set CPU_FTR_P11_PVR for Power11 and later", " processors", " - mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE", " - kcov: use WRITE_ONCE() for selftest mode stores", " - mtd: slram: remove failed entries from the device list", " - 9p: skip nlink update in cacheless mode to fix WARN_ON", " - power: supply: bq257xx: Fix VSYSMIN clamping logic", " - scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()", " - scsi: sas: Skip opt_sectors when DMA reports no real optimization hint", " - openrisc: Add full instruction cache invalidate functions", " - 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: fix UBSAN array-index-out-of-bounds in ocfs2_sum_rightmost_rec", " - 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: host: pci_generic: Fix the physical function check", " - 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()", " - s390/pkey: Check length in PKEY_VERIFYPROTK ioctl", " - s390/pkey: Check length in pkey_pckmo handler implementation", " - mtd: spi-nor: swp: Improve locking user experience", " - mtd: spi-nor: spansion: use die erase for multi-die devices only", " - mtd: rawnand: Pause continuous reads at block boundaries", " - openrisc: Fix jump_label smp syncing", " - mtd: maps: vmu-flash: fix NULL pointer dereference in initialization", " - taskstats: retain dead thread stats in TGID queries", " - irqchip/crossbar: Use correct index in crossbar_domain_free()", " - tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()", " - tpm: tpm2-sessions: wait for async KPP completion in tpm_buf_append_salt", " - sunrpc: fix uninitialized xprt_create_args structure", " - dmaengine: tegra: Fix burst size calculation", " - dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and", " ABORT_INT_MASK", " - platform/x86: dell-laptop: fix missing cleanups in init error path", " - platform/x86: ISST: Restore SST-PP control to all domains", " - 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", " - platform/x86/amd/pmc: Don't log during intermediate wakeups", " - pkey: Move keytype check from pkey api to handler", " - 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", " - hwmon: (max6697) add missing 'select REGMAP_I2C' to Kconfig", " - i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)", " - i2c: imx: fix locked bus on SMBus block-read of 0 (IRQ)", " - i2c: mediatek: fix WRRD for SoCs without auto_restart option", " - i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()", " - i2c: spacemit: fix spurious IRQ handling returning IRQ_HANDLED", " - ice: fix ice_init_link() error return preventing probe", " - tcp: Decrement tcp_md5_needed static branch", " - ufs: core: tracing: Do not dereference pointers in TP_printk()", " - xen/gntdev: fix error handling in ioctl", " - xfrm: use compat translator only for u64 alignment mismatch", " - 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()", " - NFS: Charge unstable writes by request size, not folio size", " - nvme-apple: Prevent shared tags across queues on Apple A11", " - nvmet: fix refcount leak in nvmet_sq_create()", " - netdev-genl: report NAPI thread PID in the caller's pid namespace", " - can: esd_usb: kill anchored URBs before freeing netdevs", " - can: isotp: use unconditional synchronize_rcu() in isotp_release()", " - can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER", " - can: isotp: serialize TX state transitions under so->rx_lock", " - 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: Reset register bounds before narrowing retval range in", " check_mem_access()", " - bpf,fork: wipe ->bpf_storage before bailouts that access it", " - bpf: Add missing access_ok call to copy_user_syms", " - block: remove redundant GD_NEED_PART_SCAN in add_disk_final()", " - block: fix race in blk_time_get_ns() returning 0", " - block: fix IORING_URING_CMD_REISSUE flags check in blkdev_uring_cmd", " - 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-pcache: reject option groups without values", " - 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: fix leaking uninitialized kernel memory", " - dm-integrity: fix a bug if the bio is out of limits", " - dm-integrity: don't increment hash_offset twice", " - dm-verity: avoid double increment of &use_bh_wq_enabled", " - dm-verity: fix a possible NULL pointer dereference", " - dm-verity: increase sprintf buffer size", " - dm-verity: make error counter atomic", " - dma-fence: Make dma_fence_dedup_array() robust against 0-count input", " - accel/amdxdna: Fix use-after-free in amdxdna_gem_dmabuf_mmap()", " - accel/ivpu: Reject firmware log with size smaller than header", " - 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: 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 - only expose sysfs attributes on control interface", " - 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 firmware leak in async update", " - 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", " - tracing/user_events: Fix use-after-free in user_event_mm_dup()", " - wifi: libertas_tf: fix use-after-free in lbtf_free_adapter()", " - posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu()", " - selftests/ftrace: Drop invalid top-level local in test_ownership", " - cpu: hotplug: Preserve per instance callback errors", " - cpu: hotplug: Bound hotplug states sysfs output", " - gpio: mt7621: more robust management of IRQ domain teardown", " - gpio: tegra: do not call pinctrl for GPIO direction", " - gpio: mt7621: be sure IRQ domain is created before exposing GPIO chips", " - gpio-f7188x: Add support for NCT6126D version B", " - gpio: mt7621: avoid corruption of shared interrupt trigger state", " - gpios: palmas: add .get_direction() op", " - net: sit: require CAP_NET_ADMIN in the device netns for changelink", " - net: ethernet: ti: icssg: guard PA stat lookups", " - 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", " - selftests: net: fix file owner for broadcast_ether_dst test", " - 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", " - net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for", " changelink", " - octeontx2-af: Free BPID bitmap on setup failure", " - 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", " - platform/x86/amd/pmc: Avoid logging \"(null)\" for DMI values", " - net/sched: sch_teql: move rcu_read_lock()/spin_lock() from _bh variants", " - drm/xe/userptr: Stub notifier_lock helpers when DRM_GPUSVM=n", " - pwm: rzg2l-gpt: Fix period_ticks type from u32 to u64", " - LoongArch: Fix nr passing in set_direct_map_valid_noflush()", " - LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()", " - ipmi: Fix user refcount underflow in event delivery", " - ipmi: fix refcount leak in i_ipmi_request()", " - bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()", " - rtc: renesas-rtca3: Fix PIE clear polling condition in alarm setup error", " path", " - 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", " - fhandle: reject detached mounts in capable_wrt_mount()", " - hwmon: (max1619) add missing 'select REGMAP' to Kconfig", " - tracing/probes: Fix double addition of offset for @+FOFFSET", " - net/mlx5: HWS, fix matcher leak on resize target setup failure", " - 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", " - mm/compaction: handle free_pages_prepare() properly in compaction_free()", " - irqchip/irq-riscv-imsic-early: Fix fwnode leak on state setup failure", " - s390/monwriter: Reject buffer reuse with different data length", " - mac802154: remove interfaces with RCU list deletion", " - octeontx2-pf: fix SQB pointer leak on init failure", " - selftests: net: make busywait timeout clock portable", " - llc: fix SAP refcount leak in llc_ui_autobind()", " - ipvs: use parsed transport offset in SCTP state lookup", " - macsec: don't read an unset MAC header in macsec_encrypt()", " - dibs: loopback: validate offset and size in move_data()", " - net: macb: drop in-flight Tx SKBs on close", " - arm64: smp: Fix hot-unplug tearing by forcing unregistration", " - cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()", " - fs/resctrl: Free mon_data structures on rdt_get_tree() failure", " - fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list", " - ata: libata-core: Skip HPA resize for locked drives", " - ata: libata-core: Allow capacity transition to zero for locked drives", " - riscv: Prevent NULL pointer dereference in machine_kexec_prepare()", " - tracing/osnoise: Call synchronize_rcu() when unregistering", " - s390/diag: Add missing array_index_nospec() call to", " memtop_get_page_count()", " - s390/mm: Fix type mismatch in get_align_mask().", " - selftests/rseq: Fix a building error for riscv arch", " - 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", " - selftests/landlock: Skip scoped_signal subtest with MSG_OOB if not", " available", " - selftests/landlock: Fix screwed up pointers in the scoped_signal_test", " - mmc: sdhci-esdhc-imx: restore pinctrl before restoring ios timing on", " resume", " - powerpc/pseries: fix memory leak on krealloc failure in papr_init", " - net/mlx5: free mlx5_st_idx_data on final dealloc", " - wifi: rt2x00: avoid full teardown before work setup in probe", " - wifi: mwifiex: fix roaming to different channel in host_mlme mode", " - wifi: mac80211: fix memory leak in ieee80211_register_hw()", " - wifi: brcmfmac: cyw: fix heap overflow on a short auth frame", " - riscv: vdso: Do not use LTO for the vDSO", " - 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", " - reset: sunxi: fix memory region leak on ioremap failure", " - powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()", " - wifi: cfg80211: validate EHT MLE before MLD ID read", " - wifi: ieee80211: validate MLE common info length", " - 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", " - mmc: block: fix RPMB device unregister ordering", " - mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe()", " method", " - mmc: sdhci-esdhc-imx: remove unnecessary mmc_card_wake_sdio_irq check", " for tuning save/restore", " - mmc: sdhci-esdhc-imx: restore DLL override for DDR modes on resume", " - mmc: sdhci-esdhc-imx: fix esdhc_change_pinstate() to allow default state", " restore", " - mmc: sdhci-esdhc-imx: disable irq during suspend to fix unhandled", " interrupt", " - mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspend", " - mmc: sdhci-esdhc-imx: make non-fatal errors non-blocking in suspend", " - mmc: sdhci-esdhc-imx: fix resume error handling", " - crypto: xilinx-trng - Remove crypto_rng interface", " - 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: hid-sensor-rotation: Fix stale or zero output when reading raw", " values", " - ALSA: scarlett2: Allow selecting config_set by firmware version", " - ALSA: scarlett2: Update offsets for 2i2 Gen 4 firmware 2417", " - firmware_loader: Add cancel helper for async requests", " - ALSA: hda/tas2781: Cancel async firmware request at unbind", " - binder: Use LIST_HEAD() to initialize on stack list head", " - binder: cache secctx size before release zeroes it", " - staging: rtl8723bs: fix spaces around binary operators", " - Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister", " - Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()", " - proc: rename proc_setattr to proc_nochmod_setattr", " - usb: dwc3: Support USB3340x ULPI PHY high-speed negotiation.", " - usb: dwc3: fix dwc3_readl() and dwc3_writel() calls in dwc3_ulpi_setup()", " - usb: atm: ueagle-atm: use dev_dbg() for 'device found' message", " - usb: atm: ueagle-atm: remove function entry/exit debug messages", " - usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()", " - btrfs: remove folio parameter from ordered io related functions", " - KVM: arm64: Ensure level is always initialized when relaxing perms", " - KVM: arm64: Fix propagation of TLBI level in", " kvm_pgtable_stage2_relax_perms()", " - mm/damon/core: always put unsuccessfully committed target pids", " - mm/damon/core: trace esz at first setup", " - samples/damon/mtier: fail early if address range parameters are invalid", " - perf callchain: Handle multiple address spaces", " - soc: fsl: qe_ports_ic: Add missing cleanup on device removal", " - drm/rockchip: inno-hdmi: Switch to drmm_kzalloc()", " - accel/amdxdna: Create shared functions for AIE2 and AIE4", " - Revert \"UBUNTU: SAUCE: accel/amdxdna: Support sensors for column", " utilization\"", " - accel/amdxdna: Support sensors for column utilization", " - accel/amdxdna: Adjust size for copy_to_user()", " - accel/amdxdna: Handle DETACH_DEBUG_BO through config_debug_bo path", " - accel/amdxdna: Fix order of canceled mailbox messages", " - accel/amdxdna: Guard management mailbox channel cleanup against NULL", " pointer", " - drm/amdkfd: fix redundant MQD iterations in GFX v12.1", " - wifi: ath12k: Fix invalid IRQ requests during AHB probe", " - libbpf: Fix deduplication of typedef with base definitions", " - spi: atcspi200: Use helper function devm_clk_get_enabled()", " - spi: atcspi200: fix use-after-free when driver unbind", " - arm64: dts: rockchip: Fix vdec register blocks order on RK3576", " - arm64: dts: rockchip: Update vdec register blocks order on RK3588", " - dt-bindings: net: bluetooth: qualcomm: Fix WCN6855 regulator names", " - x86/bug: Add printf() validation to HAVE_ARCH_BUG_FORMAT_ARGS WARNs", " - arm64: dts: qcom: milos: Reduce rmtfs_mem size to 2.5MiB", " - arm64: dts: qcom: sdm845-oneplus: Drop address from framebuffer node", " - arm64: dts: qcom: sdm845-shift-axolotl: Correct touchscreen sleep state", " - soc: xilinx: Fix race condition in event registration", " - wifi: ath11k: cancel SSR work items during PCI shutdown", " - ixgbe: fix unaligned u32 access in ixgbe_update_flash_X550()", " - objtool/klp: Fix is_uncorrelated_static_local() for Clang", " - objtool/klp: Fix .data..once static local non-correlation", " - objtool/klp: Fix create_fake_symbols() skipping entsize-based sections", " - objtool/klp: Fix handling of zero-length .altinstr_replacement sections", " - objtool/klp: Fix cloning of zero-length section symbols", " - objtool/klp: Fix extraction of text annotations for alternatives", " - objtool/klp: Fix relocation conversion failures for R_X86_64_NONE", " - objtool/klp: Use sym->demangled_name for symbol_name hash", " - objtool/klp: Match symbols based on demangled_name for global variables", " - objtool: Replace iterator callback with for_each_sym_by_mangled_name()", " - objtool: Fix reloc hash collision in find_reloc_by_dest_range()", " - klp-build: Fix hang on out-of-date .config", " - klp-build: Fix checksum comparison for changed offsets", " - riscv: dts: microchip: gpio controllers on mpfs need 2 interrupt cells", " - riscv: dts: microchip: remove gpio hogs from beaglev-fire", " - wifi: cfg80211: restrict LMR feedback check to TB and non-TB ranging", " - drm/panel: Clean up SOFEF00 config dependencies", " - drm/panel: Clean up S6E3FC2X01 config dependencies", " - arm64: dts: marvell: samsung-coreprimevelte: Increase touchscreen", " voltage", " - arm64: dts: imx8mn-vhip4-evalboard-v1: Correct interrupt flags", " - arm64: dts: imx8mn-vhip4-evalboard-v2: Correct interrupt flags", " - crypto: ccp - Check for page allocation failure correctly in TIO", " - crypto: ccp - Initialize data during __sev_snp_init_locked()", " - accel/amdxdna: Fix clflush buffer size", " - ntb: Store original DMA address for future release", " - ntb: Use consistent DMA attributes when freeing DMA mappings", " - riscv: dts: spacemit: k3: add clock tree", " - dts: riscv: spacemit: correct 32k clock frequency", " - arm64: dts: qcom: sdm660: set cdsp compute-cbs' regs properly", " - arm64: dts: qcom: sdm630: set adsp compute-cbs' regs properly", " - arm64: dts: qcom: lemans: Move PCIe devices into soc node", " - sockptr: fix usize check in copy_struct_from_sockptr() for user pointers", " - arm64: dts: mediatek: mt7988a-bpi-r4pro: rework pcie gpio-hog handling", " - rhashtable: give each instance its own lockdep class", " - thermal: hwmon: Register a hwmon device for each thermal zone", " - crypto: ccp/sev-dev-tsm - bail out early when pdev->bus is NULL", " - crypto: safexcel - Fix potential memory leak in safexcel_pci_probe()", " - net/sched: add qdisc_qlen_inc() and qdisc_qlen_dec()", " - net/sched: sch_dualpi2: annotate data-races in dualpi2_dump_stats()", " - tools/rtla: Fix --dump-tasks usage in timerlat", " - rtla: Stop the record trace on interrupt", " - dm: limit target bio polling to one shot", " - selftests/bpf: Override EXTRA_LDFLAGS for static builds", " - sched/fair: Update util_est after updating util_avg during dequeue", " - hfs: fix incorrect inode ID assignment in hfs_new_inode()", " - vfio: selftests: Fix out-of-tree build with make O=", " - vfio: selftests: Allow builds when ARCH=x86", " - vfio/xe: avoid duplicate reset in xe_vfio_pci_reset_done", " - arm64: dts: qcom: kaanapali: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sdm845-xiaomi-beryllium: Correct IPA FW path", " - ASoC: mediatek: mt8189: Fix probe resource cleanup", " - drm/msm/mdss: correct UBWC programming sequences", " - tools/nolibc: stackprotector: Avoid stalling program startup if crng is", " not init yet", " - ASoC: dapm: Fix widget lookup with prefixed names across DAPM contexts", " - ACPI: PAD: Fix teardown ordering in acpi_pad_remove()", " - wifi: ath12k: fix error unwind on arch_init() failure in PCI probe", " - cpufreq: governor: Fix data races on per-CPU idle/nice baselines", " - cpufreq: governor: Fix stale prev_cpu_nice spike when enabling", " ignore_nice_load", " - dt-bindings: vendor-prefixes: Add Verbatim Corporation", " - drm/tegra: fbdev: Do not assign to struct drm_fb_helper.info", " - rust: devres: add 'static bound to Devres", " - lib/base64: validate before writing in decode tail path", " - rust: uaccess: use INLINE_COPY_TO_USER to guard copy_to_user()", " - uaccess: unify inline vs outline copy_{from,to}_user() selection", " - uaccess: minimize INLINE_COPY_USER-related ifdefery", " - crypto: ccp/tsm - Enable the root port after the endpoint", " - firmware: samsung: acpm: Add devm_acpm_get_by_phandle helper", " - firmware: samsung: acpm: remove compile-testing stubs", " - drm/msm/a8xx: Make a8xx_recover IFPC safe", " - drm/msm/a8xx: Fix RSCC offset", " - EDAC/igen6: Fix memory topology parsing for Panther Lake-H SoCs", " - arm: dts: bcm2711: Fix typo in gpio-line-names", " - arm64: dts: renesas: r8a78000: Fix GIC-720AE View 1 Redistributor", " description", " - arm64: dts: renesas: ironhide: Describe all reserved memory", " - md: replace wait loop with wait_event() in md_handle_request()", " - md/raid1,raid10: fix deadlock in read error recovery path", " - md/raid1,raid10: fix error-path detection with md_cloned_bio()", " - md/raid1,raid10: fix bio accounting for split md cloned bios", " - liveupdate: Use refcount_t for FLB reference counts", " - liveupdate: Reference count incoming FLB data", " - liveupdate: skip serialization for context-preserving kexec", " - liveupdate: fix TOCTOU race in luo_session_retrieve()", " - liveupdate: block session mutations during reboot", " - spi: imx: replace dmaengine_terminate_all() with", " dmaengine_terminate_sync()", " - wifi: ath12k: fix memory leak in ath12k_wifi7_dp_rx_h_verify_tkip_mic()", " - wifi: ath12k: fix inconsistent arvif state in vdev_create error paths", " - ACPI: button: Fix lid_device value leak past driver removal", " - drm/amd/pm: Add empty string validation to sysfs store functions", " - accel/amdxdna: Return errors for failed debug BO commands", " - mm: preserve PG_dropbehind flag during folio split", " - perf/x86/intel/uncore: Fix PCI device refcount leak in UPI discovery", " - wifi: wlcore: enable the right set of ciphers", " - cxl/test: Fix __fortify_panic", " - bpf: Take mmap_lock in zap_pages()", " - ocfs2: fix out-of-bounds write in ocfs2_remove_refcount_extent", " - cxl/pci: Fix the incorrect check of pci_read_config_word() return", " - cxl/pci: Convert PCIBIOS errors to errno on DVSEC config accesses", " - netfilter: cttimeout: detach dataplane timeout policy and repurpose", " refcount", " - arm64: dts: imx94: fix DDR PMU interrupt number", " - arm64: dts: freescale: fsl-ls1028a-tqmls1028a-mbls1028a: switch mmc", " aliases", " - selftests/bpf: Fix flaky file_reader test", " - riscv: alternative: Use IS_ENABLED() over ifdeffery for", " apply_vdso_alternatives()", " - riscv: alternative: Pass vDSO start as parameter to", " apply_vdso_alternatives()", " - riscv: alternative: Also patch the CFI vDSO", " - bpf: Verifier support for sleepable tracepoint programs", " - bpf: Reject sleepable BPF_LSM_CGROUP programs at load time", " - netfilter: flowtable: avoid num_encaps underflow on bridge VLAN untag", " - filelock: fix break_lease() stub signature for CONFIG_FILE_LOCKING=n", " - wifi: mac80211: bound S1G TIM PVB walk to the TIM element", " - ACPI: processor: Add cpuidle driver check in", " acpi_processor_register_idle_driver()", " - RDMA/nldev: Fix locking when accessing mr->pd", " - scsi: ufs: core: Handle PM commands timeout before SCSI EH", " - iommufd: Destroy the pages content after detaching from dmabuf", " - lib/test_hmm: fix memory leak in dmirror_migrate_to_system()", " - rust: kbuild: show the right `quiet_cmd_rustc_procmacrolibrary`", " - remoteproc: qcom_q6v5_wcss: drop redundant wcss_q6_bcr_reset", " - wifi: mt76: mt7996: remove redundant pdev->bus check in probe", " - wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bits", " - memory: tegra186-emc: stop borrowing MC aggregate hook for EMC", " - PM: QoS: Fix misc device registration unwind", " - btrfs: lzo: reject compressed segment that overflows the compressed", " input", " - ixgbe: do not configure xps for XDP queues", " - bpf: Cancel special fields on map value recycle", " - clocksource: move NXP timer selection to drivers/clocksource", " - [Config] Allow certain NXP timer selections for arm64", " - vduse: fix compat handling for VDUSE_IOTLB_GET_FD/VDUSE_VQ_GET_INFO", " - iomap: pass the correct len to fserror_report_io in __iomap_write_begin", " - ASoC: cs35l56: Prevent double-free of debugfs", " - ASoC: cs35l56: Cleanup if component_probe fails", " - hwmon: (gpd-fan): drop global driver data and use per-device allocation", " - hwmon: (gpd-fan): Initialize EC before registering hwmon device", " - hwmon: (gpd-fan): fix race condition between device removal and sysfs", " access", " - ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT", " - cxl/test: Verify cmd->size_in before accessing payload", " - m68k: mcf5441x: fix clocks numbering", " - pinctrl: airoha: an7583: add missed gpio32 pin group", " - pinctrl: airoha: an7583: fix misprint in gpio19 pinconf", " - pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin", " function", " - pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin", " function", " - pinctrl: airoha: fix pwm pin function for an7581 and an7583", " - pinctrl: airoha: an7583: fix gpio21 pin group", " - pinctrl: airoha: an7583: add missed gpio22 pin group", " - pinctrl: airoha: an7583: fix phy1_led1 pin function", " - pinctrl: airoha: an7583: remove undefined groups from pcm_spi pin", " function", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_setup() for non-", " serdev device", " - Bluetooth: btintel: Replace CNVi id with hardware variant", " - Bluetooth: btintel: Add DSBR support for ScP2 onwards", " - Bluetooth: btintel_pcie: Load IOSF debug regs by controller variant", " - ASoC: cs35l56: Fix wrong error test on simple_write_to_buffer()", " - ASoC: SOF: Intel: select SND_SOC_SDW_UTILS=y from", " SND_SOC_SOF_HDA_GENERIC=y", " - ASoC: meson: aiu: Validate written enum values", " - ASoC: topology: Check PCM and DAI name strings before use", " - ipv4: fib: Don't dump dying fib_info in fib_leaf_notify().", " - iommu/dma-iommu: Fix wrong scatterlist length assignment in P2PDMA path", " - iommufd: Clarify IOAS_MAP_FILE dma-buf support", " - cxl/region: Fill first free targets[] slot during auto-discovery", " - vfio: selftests: Ensure libvfio output dirs are always created", " - cxl/region: Block region delete during region creation", " - cxl/region: Resolve region deletion races", " - cxl/memdev: Pin parents for entire memdev lifetime", " - net: airoha: Fix error handling in airoha_ppe_flush_sram_entries()", " - netfilter: nft_fwd_netdev: use recursion counter in neigh egress path", " - netfilter: nf_dup_netdev: add nf_dev_xmit_recursion*() helpers and use", " them", " - geneve: Fix off-by-one comparing with GRO_LEGACY_MAX_SIZE", " - smb: client: fix conflicting option validation for new mount API", " - btrfs: Drop WQ_PERCPU from ordered_flags in btrfs_init_workqueues()", " - bpf: Guard __get_user acesss with access_ok for uprobe_multi data", " - net: ti: icssg-prueth: Fix AF_XDP fill ring alloc and wakeup condition", " - net: ti: icssg: Use undirected TX tag for native XDP in HSR offload mode", " - net: ti: icssg: Use undirected TX tag for XDP zero copy in HSR offload", " mode", " - RDMA/bnxt_re: Free CQ toggle page after firmware teardown", " - RDMA/bnxt_re: Reject GET_TOGGLE_MEM when toggle page was not allocated", " - RDMA/hns: Fix memory leak of bonding resources", " - mfd: bd72720: Drop BUCK11 ID", " - 9p: Add missing read barrier in virtio zero-copy path", " - perf dwarf-aux: Fix libdw segmentation fault in cu_walk_functions_at", " - perf dwarf-aux: Fix libdw API contract violations", " - perf srcline: Introduce inline_node__clear_frames()", " - perf libdw: Fix libdw API contract violations and memory leaks", " - perf probe-finder: Fix libdw API contract violations", " - perf annotate-data: Fix libdw API contract violations", " - coresight: tmc: Fix overflow when calculating is bigger than 2GiB", " - perf tool: Fix missing schedstat delegates and dont_split_sample_group", " in delegate_tool", " - PCI: intel-gw: Move interrupt enable to own function", " - PCI: intel-gw: Enable clock before PHY init", " - PCI: intel-gw: Add .start_link() callback", " - bus: mhi: ep: Add missing state_lock protection for mhi_state access", " - PCI: dwc: Apply ECRC workaround for DesignWare cores prior to 5.10a", " - PCI: qcom: Set max OPP before DBI access during resume", " - perf pmu-events AMD: Switch l2_itlb_misses to", " bp_l1_tlb_miss_l2_tlb_miss.all", " - perf unwind: Refactor get_entries to allow dynamic libdw/libunwind", " selection", " - coresight: Handle helper enable failure properly", " - mailbox: don't free the channel if the startup callback failed", " - PCI/pwrctrl: Lock device when calling device_is_bound()", " - coresight: platform: defer connection counter increment until alloc", " succeeds", " - platform/x86: classmate-laptop: Address memory leaks on driver removal", " - clk: microchip: mpfs-ccc: fix peripheral driver registration failures", " after oob fix", " - perf sample: Add evsel to struct perf_sample", " - perf event: Fix size of synthesized sample with branch stacks", " - perf inject: Fix itrace branch stack synthesis", " - gpib: cb7210: Fix region leak when request_irq fails", " - timers/migration: Update stale @online doc to @available", " - clk: spacemit: k3: Switch to pll2_d6 as parent for PCIe clock", " - clk: spacemit: k3: Fix PCIe clock register offset", " - fs/ntfs3: fix wrong LCN in run_remove_range() when splitting a run", " - ntfs3: Allocate iomap inline_data using alloc_page", " - perf sample: Add file_offset field to struct perf_sample", " - perf sched: Replace BUG_ON on invalid CPU with graceful skip", " - perf sched: Fix NULL dereference in latency_runtime_event", " - perf sched: Fix comp_cpus heap overflow with cross-machine recordings", " - perf tools: Guard remaining test_bit calls from OOB sample CPU", " - perf sched: Fix thread reference leaks in timehist_get_thread()", " - perf sched: Use is_idle_sample() for idle thread runtime cast guard", " - perf sched: Fix thread reference leak in idle hist processing", " - perf sched: Free callchain nodes in idle thread cleanup", " - docs: memfd_preservation: fix rendering of ABI documentation", " - virtio: add missing kernel-doc for map and vmap members", " - fs/ntfs3: prevent potential lcn remains uninitialized", " - perf tools: NULL bitmap pointers after bitmap_free()", " - perf tools: Use scnprintf() in build_id__snprintf() and hwmon", " read_events()", " - perf data convert json: Fix addr_location leak on time-filtered samples", " - perf tools: Use mkostemp() for O_CLOEXEC on temporary files", " - phy: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put", " in reset", " - sparc: Avoid -Wunused-but-set-parameter in clear_user_page()", " - apparmor: release exe file resources on path failure", " - apparmor: remove unnecessary goto and associated label", " - apparmor: Fix inverted comparison in cache_hold_inc()", " - i3c: mipi-i3c-hci: Fix suspend behavior when bus disable falls back to", " software reset", " - i3c: master: Serialize i3c_set_hotjoin() with the maintenance lock", " - i3c: mipi-i3c-hci: Fix race in i3c_hci_addr_to_dev()", " - perf maps: Add maps__mutate_mapping", " - perf c2c: Free format list entries when releasing c2c hist entries", " - regcache: Do not overwrite error code when finalizing cache after error", " - erofs: call erofs_exit_ishare() before rcu_barrier()", " - perf c2c: Free format list entries when c2c_hists__init() fails", " - perf c2c: Fix hist entry and format list leaks in c2c_he_free()", " - drm/amd/display: Skip PHY SSC reduction on some 8K panels", " - net: ethernet: mtk_eth_soc: fix supported_interface set after", " phylink_create", " - selftests/ftrace: Fix trace_marker_raw test on 64K page kernels", " - octeontx2-af: npc: Log successful MCAM drop-on-non-hit install at debug", " level", " - netconsole: don't drop the last byte of a full-sized message", " - eth: fbnic: take netif_addr_lock_bh() around rx mode address programming", " - arm64: static_call: include asm/insns.h", " - md/raid1: fix writes_pending and barrier reference leaks on write", " failures", " - md/raid10: fix writes_pending leak on write request failures", " - md/raid10: fix writes_pending and barrier reference leaks on discard", " failures", " - netfilter: ipset: Don't use test_bit() in lockless RCU readers in bitmap", " types", " - selftests/mm: fix hugetlb pathname construction in", " charge_reserved_hugetlb.sh", " - selftests/mm: run_vmtests.sh: free memory if available memory is low", " - selftests/mm: move hwpoison setup into run_test() and silence modprobe", " output for memory-failure category", " - selftests/mm: remove hardcoded THP sizing assumptions in hmm tests", " - net: dst_metadata: fix false-positive memcpy overflow in tun_dst_unclone", " - bpf: Fix partial copy of non-linear test_run output", " - bpf: Fix BPF_PROG_ASSOC_STRUCT_OPS last field check", " - erofs: handle 48-bit blocks_hi for compressed inodes", " - ASoC: cs530x: Fix expected MCLK rates for CS5302/4/8", " - PCI: endpoint: pci-epf-vntb: Document legacy MSI doorbell offset", " - PCI: endpoint: pci-epf-vntb: Defer pci_epc_raise_irq() out of atomic", " context", " - PCI: endpoint: pci-epf-vntb: Report 0-based doorbell vector via", " ntb_db_event()", " - e1000e: Reconfigure PLL clock gate timeout and re-enable K1 on Meteor", " Lake", " - bpf: Guard conntrack opts error writes", " - selftests/bpf: Cover small conntrack opts error writes", " - netfilter: nf_conntrack_helper: dynamically allocate struct", " nf_conntrack_helper", " - netfilter: nf_conntrack_pptp: move GRE specific cleanup to GRE tracker", " - netfilter: nf_conntrack_gre: fix gre keymap list corruption", " - netfilter: conntrack: check NULL when retrieving ct extension", " - netfilter: nf_conntrack_expect: use conntrack GC to reap expectations", " - netfilter: nf_conntrack_expect: store master_tuple in expectation", " - netfilter: nf_conntrack_expect: run expectation eviction with no helper", " - netfilter: nft_ct: expectation timeouts are passed in milliseconds", " - netfilter: nf_conntrack_helper: cap maximum number of expectation at", " helper registration", " - cpuidle: Allow exit latency to exceed target residency", " - ASoC: SDCA: Validate written enum value in ge_put_enum_double()", " - ASoC: rt5575: Use __le32 for SPI burst write address", " - PCI: endpoint: pci-epf-vntb: Exclude reserved slots from db_valid_mask", " - net: ti: icssg: Fix XSK zero copy TX during application wakeup", " - net: lwtunnel: Drop skb metadata before LWT encapsulation", " - sctp: fix err_chunk memory leaks in INIT handling", " - net: dsa: mxl862xx: avoid unaligned 16-bit access in api_wrap", " - octeontx2-af: fix CGX debugfs RVU AF PCI reference leaks", " - geneve: gate GRO hint in geneve_gro_complete() on gs->gro_hint", " - geneve: validate inner network offset in geneve_gro_complete()", " - tools: ynl: build archives with $(AR)", " - net: enetc: fix potential divide-by-zero when num_vsi is zero", " - udp_tunnel: Pass struct sock to setup_udp_tunnel_sock().", " - tipc: avoid busy looping in tipc_exit_net()", " - bpf: Mask pseudo pointer values in verifier logs", " - bpf: Fix insn_aux_data leak on verifier err_free_env path", " - hwmon: (pmbus/core) Add support for NVIDIA nvidia195mv mode", " - hwmon: (pmbus/core) honor vrm_version in pmbus_data2reg_vid()", " - gpio: shared-proxy: always serialize with a sleeping mutex", " - drm/panthor: Always use the IRQ-safe variant when acquiring the fence", " lock", " - drm/panthor: Keep the reset work disabled until everything is", " initialized", " - drm/panthor: Fix panthor_pwr_unplug()", " - spi: rzv2h-rspi: Fix DMA transfer error handling for signal interruption", " - xen/pvcalls: bound backend response req_id before indexing rsp[]", " - afs: Remove setting of AS_RELEASE_ALWAYS for symlinks and mountpoints", " - afs: Fix directory inode initialisation order", " - afs: Use scoped_seqlock_read() rather than manually doing seqlock stuff", " - afs: Fix leak of ungot volume", " - iomap: release pages on atomic dio size mismatch", " - cachefiles: Fix double unlock in nomem_d_alloc error path", " - cachefiles: Fix file burial to take lock when unsetting S_KERNEL_FILE", " - drm/imagination: Fix returned size for DRM_IOCTL_PVR_DEV_QUERY", " - iio: dac: mcp47feb02: Fix passing uninitialized vref1_uV for no Vref1", " case", " - net/mlx5: LAG, replace pf array with xarray", " - net/mlx5: LAG, use xa_alloc to manage LAG device indices", " - net/mlx5: Lag: refactor representor reload handling", " - net/mlx5: E-Switch, add representor lifecycle lock", " - net/mlx5: Lag, avoid LAG and representor lock cycles", " - net/mlx5: LAG, factor out shared FDB code into dedicated file", " - net/mlx5: LAG, replace peer count check with direct peer lookup", " - net/mlx5: LAG, prepare for SD device integration", " - net/mlx5: LAG, replace mlx5_get_dev_index with LAG sequence number", " - net/mlx5: LAG, extend shared FDB API with group_id filter", " - net/mlx5: LAG, Fix off-by-one in single-FDB error rollback", " - ksmbd: fix multichannel binding and enforce channel limit", " - smb: client: preserve leading slash for POSIX absolute symlink targets", " - gpio: shared: make the voting mechanism adaptable", " - drm/i915/ltphy: Fix SSC Enablement bit in PORT_CLOCK_CTL", " - Bluetooth: 6lowpan: avoid untracked enable work", " - Bluetooth: btintel_pcie: Support Product level reset", " - [Config] Make BT_INTEL_PCIE depend on ACPI", " - Bluetooth: btintel_pcie: Add support for smart trigger dump", " - Bluetooth: btintel_pcie: Separate coredump work from RX work", " - Bluetooth: btintel_pcie: Refactor FLR to use device_reprobe()", " - Bluetooth: ISO: fix malformed ISO_END/CONT handling", " - accel/amdxdna: Prevent PM resume deadlock in hwctx_sync_debug_bo()", " - accel/amdxdna: Fix VMA access race", " - net: rnpgbe: fix mailbox endianness and remove pointer casts", " - drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE", " - smb: client: fix busy dentry warning on unmount after DIO", " - drm/fb-helper: Only consider active CRTCs for vblank sync", " - ethtool: rss: Fix hfunc and input_xfrm parsing on big endian", " - drm/imagination: make pvr_fw_trace_init_mask_ops static", " - VDUSE: avoid leaking information to userspace", " - ASoC: SOF: ipc4-control: Validate notification payload size", " - arm64: dts: renesas: ironhide: Describe inline ECC carveouts", " - arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers", " - KVM: s390: vsie: Fix allocation of struct vsie_rmap", " - KVM: s390: vsie: Add missing radix_tree_preload() in", " _gaccess_shadow_fault()", " - KVM: s390: Add some useful mask macros", " - KVM: s390: vsie: Fix rmap handling in _do_shadow_crste()", " - KVM: s390: vsie: Fix redundant rmap entries", " - KVM: s390: vsie: Use mmu cache to allocate rmap", " - KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory", " - KVM: TDX: Reject concurrent change to CPUID entry count", " - ASoC: SOF: topology: fix memory leak in snd_sof_load_topology", " - netfilter: nft_fib: reject fib expression on the netdev egress hook", " - netfilter: nf_conntrack_sip: remove net variable shadowing", " - netfilter: nf_conntrack_sip: validate skb_dst() before accessing it", " - gpu/buddy: bail out of try_harder when alignment cannot be honoured", " - backlight: ktd2801: Enable BL_CORE_SUSPENDRESUME", " - cxl: Fix CXL_HEADERLOG_SIZE to match RAS Capability size", " - pinctrl: renesas: rzg2l: Use -ENOTSUPP instead of -EOPNOTSUPP", " - remoteproc: xlnx: Check remote core state", " - mm/sparse-vmemmap: fix vmemmap accounting underflow", " - mm/huge_memory: preserve pmd_swp_uffd_wp on device-private PMD downgrade", " - fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race", " - fs/proc/task_mmu: do not warn on seeing non-migration pmd entry", " - kho: make sure scratch size is always aligned by CMA_MIN_ALIGNMENT_BYTES", " - mtd: maps: vmu-flash: fix fault in unaligned fixup", " - dmaengine: dw-edma-pcie: Reject devices without driver data", " - dmaengine: sh: rz-dmac: Move interrupt request after everything is set", " up", " - platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8D26)", " - platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8E35)", " - spi: imx: reconfigure for PIO when DMA cannot be started", " - ovl: use linked upper dentry in copy-up tmpfile", " - can: bcm: add locking when updating filter and timer values", " - can: bcm: extend bcm_tx_lock usage for data and timer updates", " - can: bcm: fix CAN frame rx/tx statistics", " - can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()", " - can: bcm: fix stale rx/tx ops after device removal", " - can: bcm: track a single source interface for ANYDEV timeout/throttle", " ops", " - can: bcm: validate frame length in bcm_rx_setup() for RTR replies", " - can: bcm: add missing device refcount for CAN filter removal", " - selftests/bpf: Cover negative buffer pointer offsets", " - dm: avoid leaking the caller's thread keyring via the table device file", " - dma-buf: protected fence ops by RCU v8", " - dma-fence: use correct callback in dma_fence_timeline_name()", " - accel/amdxdna: reject command submission on devices without a submit op", " - accel/amdxdna: reject user command submission without a command BO", " - accel/amdxdna: Use caller client for debug BO sync", " - fs/resctrl: Fix use-after-free during unmount", " - mmc: vub300: fix use-after-free on probe failure", " - octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF", " - ksmbd: fix stack buffer overflow in multichannel session-key copy", " - netfilter: nfnetlink_cthelper: cap to maximum number of expectation per", " master", " - netfilter: nfnetlink_cthelper: cap to maximum number of expectation per", " master on updates", " - riscv: vdso: Always declare vdso_start symbols", " - ata: libata-core: Add NOLPM quirk for PNY CS900 1TB SSD", " - ata: libata-core: Reject an invalid concurrent positioning ranges count", " - net: ipa: fix SMEM state handle leaks in SMP2P init", " - amdkfd: properly free secondary context id", " - pmdomain: imx93-blk-ctrl: Extract PHY as shared domain for DSI/CSI", " - pmdomain: mediatek: Fix possible nullptr KP in HWV cleanup/on-check", " - arch/riscv: vdso: remove CFI landing pad from rt_sigreturn", " - reset: imx7: Correct polarity of MIPI CSI resets on i.MX8MQ", " - powerpc/uaccess: correct check for CONFIG_PPC_E500 in", " mask_user_address()", " - wifi: mac80211: validate extension-frame layout before RX", " - xfs: factor out a xfs_zone_mark_free helper", " - xfs: add newly added RTGs to the free pool in growfs", " - liveupdate: validate session type before performing operation", " - posix-timers: Expand timer_[re]arm() callbacks with a boolean return", " value", " - posix-cpu-timers: Prevent UAF caused by non-leader exec() race", " - Revert \"gpib: cb7210: Fix region leak when request_irq fails\"", " - Upstream stable to v6.18.40, v7.1.5", " * Resolute update: upstream stable patchset 2026-08-20 (LP: #2164666) //", " CVE-2023-20585", " - 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", " * [Regression] Laptop fails to power off completely when HDMI is connected", " in kernel 7.0.0-28 (LP: #2163121) // CVE-2026-68364", " - drm/amd/display: fix NULL ptr deref in ISM delayed work", " - drm/amd/display: Fix ISM teardown crash from NULL dc dereference", " - drm/amd/display: Fix ISM dc_lock deadlock during suspend", " * CVE-2026-72064", " - net: mana: Sync page pool RX frags for CPU", " * CVE-2026-72065", " - net: mana: Validate the packet length reported by the NIC", " * CVE-2026-72098", " - dm-verity-fec: replace {MAX,MIN}_RSN with {MIN,MAX}_ROOTS", " - dm-verity: fix buffer overflow in FEC calculation", " * CVE-2026-72248", " - netfilter: flowtable: support IPIP tunnel with direct xmit", " - netfilter: flowtable: use correct direction to set up tunnel route", " * CVE-2026-72249", " - netfilter: flowtable: use dst in this direction when pushing IPIP header", " * CVE-2026-72287", " - KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\"", " checks", " * CVE-2026-72329", " - net/liquidio: drop cached VF pci_dev LUT", " * CVE-2026-72355", " - netfs: Fix barriering when walking subrequest list", " * CVE-2026-72412", " - s390/mm: Fix handling of _PAGE_UNUSED pte bit", " * CVE-2026-72417", " - netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto()", " * CVE-2026-72442", " - netfilter: flowtable: fix and simplify IP6IP6 tunnel handling", " * CVE-2026-72463", " - xfrm: Fix dev use-after-free in xfrm async resumption", " * CVE-2026-72477", " - fs/ntfs3: call _ntfs_bad_inode() when failing to rename", " * CVE-2026-72493", " - net: serialize netif_running() check in enqueue_to_backlog()", " * CVE-2026-72494", " - RDMA/irdma: Replace waitqueue and flag with completion", " * CVE-2026-72496", " - RDMA/bnxt_re: Proper rollback if the ioremap fails", " * CVE-2026-74269", " - bnxt: fix head underflow on XDP head-grow", " * CVE-2026-74350", " - ocfs2: validate fast symlink target during inode read", " * CVE-2026-72495", " - RDMA/bnxt_re: Avoid repeated requests to allocate WC pages", " * CVE-2026-72501", " - RDMA/bnxt_re: Initialize dpi variable to zero", " * CVE-2026-72278", " - KVM: arm64: nv: Re-translate VNCR before injecting abort", " * CVE-2026-68083", " - ksmbd: fix path resolution in ksmbd_vfs_kern_path_create", " * CVE-2026-68457", " - ksmbd: use opener credentials for FSCTL mutations", " * CVE-2026-68476", " - ipvs: reload ip header after head reallocation", " * CVE-2026-68477", " - ipvs: fix more places with wrong ipv6 transport offsets", " * CVE-2026-72014", " - drbd: reject data replies with an out-of-range payload size", " * CVE-2026-72020", " - ipvs: reset full ip_vs_seq structs in ip_vs_conn_new", " * CVE-2026-72033", " - orangefs: keep the readdir entry size 64-bit in fill_from_part()", " * CVE-2026-72041", " - espintcp: use sk_msg_free_partial to fix partial send", " * CVE-2026-72046", " - gve: fix header buffer corruption with header-split and HW-GRO", " * CVE-2026-72069", " - locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()", " * CVE-2026-72083", " - scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE", " * CVE-2026-72084", " - scsi: target: Bound PR-OUT TransportID parsing to the received buffer", " * CVE-2026-72085", " - scsi: xen: scsiback: Free unsubmitted command instead of double-putting", " it", " * CVE-2026-72129", " - nvmet-rdma: handle inline data with a nonzero offset", " * CVE-2026-72130", " - nvmet-auth: reject short AUTH_RECEIVE buffers", " * CVE-2026-64551", " - sctp: validate STALE_COOKIE cause length before reading staleness", " * CVE-2026-72137", " - xfrm: nat_keepalive: avoid double free on send error", " * CVE-2026-72139", " - tcp: defer md5sig_info kfree past RCU grace period in tcp_connect", " * CVE-2026-72191", " - ntfs3: validate split-point offset in indx_insert_into_buffer", " * CVE-2026-72192", " - ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head", " * CVE-2026-72194", " - fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow", " * CVE-2026-72217", " - SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing", " * CVE-2026-72220", " - sunrpc: harden rq_procinfo lifecycle to prevent double-free", " * CVE-2026-72221", " - sunrpc: wait for in-flight TLS handshake callback when cancel loses race", " * CVE-2026-72222", " - sunrpc: pin svc_xprt across the asynchronous TLS handshake callback", " * CVE-2026-72226", " - batman-adv: tt: prevent TVLV OOB check overflow", " * CVE-2026-72234", " - batman-adv: access unicast_ttvn skb->data only after skb realloc", " * CVE-2026-72251", " - netfilter: nf_nat_sip: reload possible stale data pointer", " * CVE-2026-72277", " - KVM: arm64: nv: Inject SEA if kvm_translate_vncr() can't resolve PFN", " - KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory", " * CVE-2026-72279", " - KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR", " * CVE-2026-72288", " - KVM: arm64: vgic: Handle race between interrupt affinity change and LPI", " disabling", " * CVE-2026-72289", " - KVM: arm64: vgic: Check the interrupt is still ours before migrating it", " * CVE-2026-72296", " - net: ife: require ETH_HLEN to be pullable in ife_decode()", " * CVE-2026-72299", " - tipc: restrict socket queue dumps in enqueue tracepoints", " * CVE-2026-72317", " - SUNRPC: pin upper rpc_clnt across the TLS connect_worker", " * CVE-2026-72318", " - cifs: validate DFS referral string offsets", " * CVE-2026-72319", " - ipvs: fix PMTU for GUE/GRE tunnel ICMP errors", " - ipvs: ensure inner headers in ICMP errors are in headroom", " * CVE-2026-72320", " - netfilter: nft_lookup: fix catchall element handling with inverted", " lookups", " * CVE-2026-72322", " - ipv6: mcast: Fix potential UAF in MLD delayed work", " * CVE-2026-72323", " - ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()", " * CVE-2026-64541", " - net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket", " * CVE-2026-72339", " - qede: fix off-by-one in BD ring consumption on build_skb failure", " * CVE-2026-72348", " - netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop", " * CVE-2026-72351", " - gue: validate REMCSUM private option length", " * CVE-2026-72366", " - netfs: Fix netfs_create_write_req() to handle async cache object", " creation", " * CVE-2026-72381", " - ksmbd: fix use-after-free of fp->owner.name in durable handle owner", " check", " * CVE-2026-72393", " - eth: fbnic: don't cache shinfo across skb realloc", " * CVE-2026-72398", " - sctp: add INIT verification after cookie unpacking", " * CVE-2026-72399", " - net: enetc: check the number of BDs needed for xdp_frame", " * CVE-2026-64530", " - net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle", " * CVE-2026-72422", " - ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2", " NEGOTIATE", " * CVE-2026-72429", " - ipv6: ioam: fix type confusion of dst_entry", " * CVE-2026-72436", " - 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", " * CVE-2026-72451", " - xfrm: Fix xfrm state cache insertion race", " * CVE-2026-72466", " - xprtrdma: Fix bcall rep leak and unbounded peek", " * CVE-2026-72472", " - nfs: use nfsi->rwsem to protect traversal of the file lock list", " * CVE-2026-72473", " - 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", " * CVE-2026-72491", " - net/9p: fix race condition on rdma->state in trans_rdma.c", " * CVE-2026-72495 // CVE-2026-72501", " - RDMA/bnxt_re: Move the UAPI methods to a dedicated file", " * CVE-2026-74255", " - tipc: fix UAF in tipc_l2_send_msg()", " * CVE-2026-74267", " - net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek", " before restoring qlen", " * CVE-2026-74268", " - tcp: clear sock_ops cb flags before force-closing a child socket", " * CVE-2026-74287", " - sctp: validate embedded address parameter length", " * CVE-2026-74310", " - vhost/net: complete zerocopy ubufs only once", " * CVE-2026-74345", " - RDMA/siw: Fix endpoint/socket association handling", " * CVE-2026-74361", " - nvme: fix FDP fdpcidx bounds check", " * CVE-2026-74376", " - md/raid10: reset read_slot when reusing r10bio for discard", " * CVE-2026-74384", " - nvme-multipath: fix flex array size in struct nvme_ns_head", " * CVE-2026-74394", " - RDMA/srpt: fix integer overflow in immediate data length check", " * CVE-2026-74398", " - ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD", " * CVE-2026-74401", " - dlm: fix add msg handle in send_queue ordered", " * CVE-2026-74406", " - vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().", " * CVE-2026-74427", " - afs: Fix netns teardown to cancel the preallocation charger", " - afs: Fix further netns teardown to cancel the preallocation charger", " * CVE-2026-74428", " - rxrpc: Fix double unlock in rxrpc_recvmsg()", " * CVE-2026-74433", " - rxrpc: Fix UAF in rxgk_issue_challenge()", " * CVE-2026-74434", " - rxrpc: Don't move a peeked OOB message onto the pending queue", " * CVE-2026-74436", " - rxrpc: serialize kernel accept preallocation with socket teardown", " * CVE-2026-64535", " - nvmet-tcp: Fix potential UAF when ddgst mismatch", " * CVE-2026-74439", " - iommu/vt-d: Clear Present bit before tearing down scalable-mode context", " entry", " * CVE-2026-64534", " - nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error", " path", "" ], "package": "linux-riscv-7.0", "version": "7.0.0-38.38.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2165483, 2165484, 2165407, 2166547, 2166443, 2166356, 2165872, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165407, 2165040, 2161748, 2163508, 2163214, 2162904, 2162045, 2164967, 2160082, 2164504, 2156316, 2164716, 2164516, 2163375, 2162803, 2163062, 2132119, 2163293, 2160200, 2158858, 2162704, 2162695, 2164666, 2164666, 2163121 ], "author": "Sarah Emery ", "date": "Sun, 27 Sep 2026 00:11:21 +0200" } ], "notes": "linux-riscv-7.0-tools-7.0.0-38 version '7.0.0-38.38.1~24.04.1' (source package linux-riscv-7.0 version '7.0.0-38.38.1~24.04.1') was added. linux-riscv-7.0-tools-7.0.0-38 version '7.0.0-38.38.1~24.04.1' has the same source package name, linux-riscv-7.0, as removed package linux-headers-7.0.0-34-generic. As such we can use the source package version of the removed package, '7.0.0-34.34.1~24.04.1', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-tools-7.0.0-38-generic", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": null }, "to_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-38.38.1~24.04.1", "version": "7.0.0-38.38.1~24.04.1" }, "cves": [ { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-68105", "url": "https://ubuntu.com/security/CVE-2026-68105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix kernel panic during driver load failure Avoid kernel panic if MES init fails during driver load. The KIQ ring is falsely marked as ready as ASICs that use MES, KIQ is owned by MES. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] Call Trace: gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280 __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53 (cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68109", "url": "https://ubuntu.com/security/CVE-2026-68109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68114", "url": "https://ubuntu.com/security/CVE-2026-68114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit e4d99e04b2e9b13b97d3b17804c735f62689db23)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68431", "url": "https://ubuntu.com/security/CVE-2026-68431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate minimum PDU size for transform requests The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68138", "url": "https://ubuntu.com/security/CVE-2026-68138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: serialize qdisc_rtab_list against concurrent get/put qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68082", "url": "https://ubuntu.com/security/CVE-2026-68082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix two unsafe bare decodes in decode_lockers() decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-08 10:16:00 UTC" }, { "cve": "CVE-2026-68159", "url": "https://ubuntu.com/security/CVE-2026-68159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68163", "url": "https://ubuntu.com/security/CVE-2026-68163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_vma_mapped: fix device-private PMD handling Commit 65edfda6f3f2 (\"mm/rmap: extend rmap and migration support device-private entries\") introduced the concept of device-private PMD entries, but did not correctly update the rmap walk code to account for them. As a result, when page_vma_mapped_walk() encounters device-private PMD entries, it takes no action other than to acquire the PMD lock and exit. However this is highly problematic for two reasons - firstly, device private entries possess a PFN so check_pmd() needs to be called to ensure an overlapping PFN range. Secondly, and more importantly, if PVMW_MIGRATION is set the caller assumes the returned entry is a migration entry, resulting in memory corruption when the caller tries to interpret the device private entry as such. In addition, commit 146287290023 (\"mm/huge_memory: implement device-private THP splitting\") allowed device private PMDs to be split like THP mappings, but again did not update this code path. As a result, we might race a PMD split prior to acquiring the PMD lock. This patch addresses all of these issues by invoking check_pmd(), ensuring PMVW_MIGRATION is not set and checks whether a split raced us we do for PMD THP and migration entries. Instead of checking for a subset of the cases after taking the pmd_lock(), put device-private along with pmd_trans_huge() and pmd_is_migration_entry(). Also remove thp_migration_supported() as it is already guarded by pmd_is_migration_entry(). [akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68166", "url": "https://ubuntu.com/security/CVE-2026-68166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: prevent registration of special VMAs Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68170", "url": "https://ubuntu.com/security/CVE-2026-68170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix stale skb->sk reference on subflow close The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68177", "url": "https://ubuntu.com/security/CVE-2026-68177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Delay module ref count for \"enable_event\" trigger Triggers are now delayed from freeing, but can still be triggered until after the RCU grace period has ended. The freeing of the enable_event data is put into the private_data_free() callback, but the put of the module refcount is done immediately. It is possible that if a module is removed that has an event that would enable (or disable) it is still active, it can read the data of the module after it is removed causing a use-after-free bug. Move the trace_event_put_ref() that releases the module into the delayed callback so that the module can not be removed until any reference to its events are finished.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68191", "url": "https://ubuntu.com/security/CVE-2026-68191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix NULL pointer dereference in rhash table destroy When unbinding the ath12k driver, kernel NULL pointer dereferences occur in irq_work_sync() called from rhashtable_destroy(). Two hash tables are affected: 1. ath12k_link_sta hash table in ath12k_base 2. ath12k_dp_link_peer hash table in ath12k_dp The issue happens because the destroy functions are called unconditionally in cleanup paths, but the hash tables are only initialized late in their respective init functions. If the device was never fully started or if the init functions failed before initializing the hash tables, the pointers will be NULL. The issues are always reproducible from a VM because the MSI addressing initialization is failing. Call trace for ath12k_link_sta_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_link_sta_rhash_tbl_destroy+0x19/0x40 [ath12k] ath12k_core_stop+0xe/0x80 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Call trace for ath12k_dp_link_peer_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_dp_link_peer_rhash_tbl_destroy+0x29/0x50 [ath12k] ath12k_dp_cmn_device_deinit+0x21/0x140 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Fix this by adding NULL checks before calling rhashtable_destroy() in both destroy functions. The NULL check approach was chosen because the rhashtable pointer serves as the initialization state indicator. The init can fail at various points, leaving some components uninitialized. Checking the pointer directly is simpler than adding separate state flags that would need synchronization.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64586", "url": "https://ubuntu.com/security/CVE-2026-64586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: drain bus_reset work on device removal brcmf_fw_crashed() and the debugfs \"reset\" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs \"reset\" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. 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-68208", "url": "https://ubuntu.com/security/CVE-2026-68208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: Fix the error code of devm_kzalloc() in vip_probe_slice() In vip_probe_slice(), the error check for devm_kzalloc() incorrectly uses PTR_ERR_OR_ZERO() which returns 0 for NULL pointer. Return -ENOMEM for devm_kzalloc() failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68224", "url": "https://ubuntu.com/security/CVE-2026-68224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mali-c55: Fix possible ERR_PTR in enable_streams The media_pad_remote_pad_unique() function returns either a valid pointer or an ERR_PTR() on failure (-ENOTUNIQ if multiple links are enabled, -ENOLINK if no connected pad is found). The return value was assigned directly to isp->remote_src and dereferenced in the next line without checking for errors, which could lead to an ERR_PTR dereference. Add proper error checking with IS_ERR() before dereferencing the pointer. Also set isp->remote_src to NULL on error to maintain consistency with other error paths in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68237", "url": "https://ubuntu.com/security/CVE-2026-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: fix indefinite fence wait during GPU reset pre_reset only force-completes fences of MAPPED queues. A queue in any other state (e.g. mid-eviction) keeps its last_fence pending; after a GPU reset that fence never signals, so the eviction/suspend worker and process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and wedge the machine: INFO: task kworker/6:28 blocked for more than 120 seconds. Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu] Call Trace: dma_fence_wait_timeout+0x7e/0x130 amdgpu_userq_evict+0x67/0x140 [amdgpu] amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu] process_scheduled_works+0xa6/0x420 Force-complete every queue's fence regardless of state. The unmap and mark-hung step stays gated on MAPPED, since unmapping a queue that is not mapped is invalid. (cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68240", "url": "https://ubuntu.com/security/CVE-2026-68240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: publish dpagemap early to avoid device mapping leak on error drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68242", "url": "https://ubuntu.com/security/CVE-2026-68242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix NULL deref on sched_engine alloc failure Avoid using intel_context_put() before intel_context_init() in execlists_create_virtual() as the kref_put() inside would lead to NULL deref on the IOCTL path when sched_engine allocation fails. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68254", "url": "https://ubuntu.com/security/CVE-2026-68254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: require valid min/max vfreq for VRR Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68436", "url": "https://ubuntu.com/security/CVE-2026-68436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use kvzalloc to allocate struct dc struct dc has grown large over time (most of it the two inlined dc_scratch_space copies) and now sits close to the page allocator's 4 MiB contiguous allocation limit. Its actual size is not fixed by the source alone, it also depends on the compiler and the .config, so it can easily cross 4 MiB, e.g. with a newer GCC or a config change. dc_create() allocates it with kzalloc(). Once struct dc exceeds 4 MiB the request is rounded up to order 11 (8 MiB), which is above MAX_PAGE_ORDER, so the page allocator warns and returns NULL. dc_create() then fails, DM init fails and amdgpu probe aborts with -EINVAL: WARNING: mm/page_alloc.c:5197 at __alloc_frozen_pages_noprof+0x2f9/0x380 dc_create+0x38/0x660 [amdgpu] amdgpu_dm_init+0x2d9/0x510 [amdgpu] dm_hw_init+0x1b/0x90 [amdgpu] amdgpu_device_init.cold+0x150d/0x1e13 [amdgpu] amdgpu_driver_load_kms+0x19/0x80 [amdgpu] amdgpu_pci_probe+0x1e2/0x4c0 [amdgpu] dc_create() then returns NULL and DM init fails, which aborts the whole GPU init and makes amdgpu probe fail with -EINVAL (\"hw_init of IP block failed -22\"), leaving the display unusable. The subsequent amdgpu_irq_put() warnings during teardown are just fallout of unwinding a half-initialized device. struct dc is a software-only bookkeeping structure that is never handed to hardware DMA and is only ever kept as an opaque pointer, so it does not require physically contiguous memory. Allocate it with kvzalloc() (and free it with kvfree()) so that the allocator can fall back to vmalloc() when a contiguous allocation of that size is not available, which also avoids the MAX_PAGE_ORDER warning entirely. v2: - Rebase to amd-staging-drm-next. (cherry picked from commit 991e0516a8072f2292681c6ae98a924ab0e32575)", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68447", "url": "https://ubuntu.com/security/CVE-2026-68447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size from hardware without bounding it to the allocated BO region. If the HW field is larger than the queue's control stack allocation, memcpy reads past the BO into adjacent GTT memory and can leak kernel data to userspace. Store the page-aligned control stack BO size in mqd_manager and clamp checkpoint copies and reported checkpoint sizes to min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound for multi-XCC v9.4.3 checkpoint layout. (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3)", "cve_priority": "high", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68264", "url": "https://ubuntu.com/security/CVE-2026-68264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: Reset current_op in xe_pt_update_ops_init() xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it. After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind. Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry. Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(). v2 (Matt): - Add details in commit message. - Add Fixes tag and Cc to stable@vger.kernel.org (cherry picked from commit 046045543e530605c441063535e7dca0075369a6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68265", "url": "https://ubuntu.com/security/CVE-2026-68265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO's tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference (cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68267", "url": "https://ubuntu.com/security/CVE-2026-68267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists Unconditionally whitelisting OA registers is a security violation. Set RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers don't get whitelisted by default after probe, gt reset, resume and engine reset. (cherry picked from commit 90511bdcfda97211c01f1d945d4ea616578d8fca)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68273", "url": "https://ubuntu.com/security/CVE-2026-68273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68274", "url": "https://ubuntu.com/security/CVE-2026-68274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix buffer overflow in steered register list allocation The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt->fuse_topo.g_dss_mask, ...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68283", "url": "https://ubuntu.com/security/CVE-2026-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free freeing trigger private data Commit 61d445af0a7c (\"tracing: Add bulk garbage collection of freeing event_trigger_data\") moved the kfree() of event_trigger_data to a kthread that runs tracepoint_synchronize_unregister() before freeing. That removed the synchronization the trigger .free callbacks used to get implicitly and inline from trigger_data_free(). event_hist_trigger_free(), event_hist_trigger_named_free() and event_enable_trigger_free() free their satellite data (hist_data, cmd_ops, enable_data) right after trigger_data_free() returns. With the synchronization now deferred to the kthread, a concurrent tracepoint handler can still reach that data through the list_del_rcu()'d trigger, causing a use-after-free. The histogram teardown must stay synchronous: remove_hist_vars() and unregister_field_var_hists() have to detach a synthetic event from the histogram before the trigger-removal write returns, otherwise a following command races in and the synthetic-event removal fails with -EBUSY, as the trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait with the correct barrier - tracepoint_synchronize_unregister(), matching the free kthread - before freeing. The enable trigger has no such synchronous requirement, and a blocking synchronize there would re-serialize the path that commit deliberately deferred. Give it an optional private_data_free() callback that the free kthread runs after its grace period, and free enable_data from there.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68286", "url": "https://ubuntu.com/security/CVE-2026-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68287", "url": "https://ubuntu.com/security/CVE-2026-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix size calculations for 64-bit attributes net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68288", "url": "https://ubuntu.com/security/CVE-2026-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68289", "url": "https://ubuntu.com/security/CVE-2026-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68291", "url": "https://ubuntu.com/security/CVE-2026-68291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix max_vport related crash on allocation error during init Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000 [ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000 [ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20 [ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000 [ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0 [ 320.417385] PKRU: 55555554 [ 320.417398] Call Trace: [ 320.417412] [ 320.417429] pci_device_remove+0x42/0xb0 [ 320.417459] device_release_driver_internal+0x1a9/0x210 [ 320.417492] driver_detach+0x4b/0x90 [ 320.417516] bus_remove_driver+0x70/0x100 [ 320.417539] pci_unregister_driver+0x2e/0xb0 [ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0 [ 320.417592] ? kmem_cache_free+0x31e/0x550 [ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190 [ 320.417644] ? do_syscall_64+0x38/0x6b0 [ 320.417665] do_syscall_64+0xc8/0x6b0 [ 320.417683] ? clear_bhb_loop+0x30/0x80 [ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 320.417727] RIP: 0033:0x7f963bb30beb", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68303", "url": "https://ubuntu.com/security/CVE-2026-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hvs/v3d: Fix null dereference in unbind The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68312", "url": "https://ubuntu.com/security/CVE-2026-68312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and cifs_close_deferred_file_under_dentry(), when a pending deferred close is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to add the file to the local processing list may fail under memory pressure. The loop breaks immediately, but the cancelled work is no longer pending (it would have called _cifsFileInfo_put()), and the cfile is never added to file_head for processing. The cifsFileInfo reference and the open server handle both leak. Fix by saving the cfile that failed allocation in a local variable, breaking as before, and calling _cifsFileInfo_put() on it after releasing the lock. Any files later in the iteration are unaffected since their deferred work is still pending and will fire normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68316", "url": "https://ubuntu.com/security/CVE-2026-68316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Fix element size accounting for cmd stream validation There are 2 issues with the element size handling in the command stream validation which result in too small of a size calculated when the element size is 16/32/64 bits. For NHWC format, the element size is simply missing from the calculation. The bitfield for the element size is different between IFM/IFM2 and OFM. IFM and IFM2 encode the precision in parameter bits 2:3, while OFM uses bits 1:2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68440", "url": "https://ubuntu.com/security/CVE-2026-68440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix heap overflow when reading module EEPROM txgbe_read_eeprom_hostif() always copies round_up(length, 4) bytes into the caller buffer, which ethtool allocates with exactly 'length' bytes. A non-4-aligned length therefore causes an out-of-bounds write. Copy only the remaining bytes on the final dword instead.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68323", "url": "https://ubuntu.com/security/CVE-2026-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: serialize udp bearer replicast list updates tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68441", "url": "https://ubuntu.com/security/CVE-2026-68441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected. This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d (\"bpf: add bpf_redirect() helper\"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available. commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs. Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a wrapper around tcf_classify() for use by qdisc classify functions and tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT, the wrapper converts it to TC_ACT_SHOT, dropping the packet rather than letting it continue silently. Dropping is preferred over letting the packet through because the user immediately sees packet loss. Silently passing the packet through would hide the problem and leave the user wondering why their redirect is not working. The clsact fast path, tc_run() continues to call tcf_classify() directly and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by sch_handle_egress/ingress() calling skb_do_redirect() as before.", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68337", "url": "https://ubuntu.com/security/CVE-2026-68337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject redirect helpers without a bpf_net_context The bpf_redirect*() helpers and skb_do_redirect() obtain the per-task bpf_redirect_info via bpf_net_ctx_get_ri(), which dereferences the current->bpf_net_context unconditionally. That context is established on the paths that run tc BPF such as sch_handle_{ingress,egress}(), *except* for the case where {cls,act}_bpf was attached to a proper qdisc. A program running from there reaches the NULL deref in two ways: * It calls bpf_redirect() directly, which dereferences the context at the top of the helper: tc qdisc add dev eth0 root handle 1: red limit 1MB min 10KB max 20KB \\ avpkt 1000 burst 100 qevent early_drop block 10 tc filter add block 10 pref 1 bpf obj redirect.o * It simply returns TC_ACT_REDIRECT without helper call: tcf_qevent_handle() then dispatches to skb_do_redirect(), which dereferences the context Rather than extending bpf_net_context management into the qdisc path, make the redirect helpers refuse to operate when no context exists, and have tcf_qevent_handle() drop a TC_ACT_REDIRECT verdict instead of calling skb_do_redirect(). Previous behaviour was a crash, so nothing regresses by not supporting it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68345", "url": "https://ubuntu.com/security/CVE-2026-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm_mpam: guard MBWU state before adding it to garbage __destroy_component_cfg() adds each RIS mbwu_state object to the MPAM garbage list when destroying component configuration. However, mbwu_state is allocated per RIS and only for RISes with MBWU monitors. A component can therefore have comp->cfg allocated while some RISes still have ris->mbwu_state set to NULL. Passing a NULL mbwu_state to add_to_garbage() dereferences the NULL pointer inside the macro. Skip RISes that do not have an mbwu_state object before adding them to the garbage list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68347", "url": "https://ubuntu.com/security/CVE-2026-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68375", "url": "https://ubuntu.com/security/CVE-2026-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle partially initialized auxiliary devices bnxt_aux_devices_init() calls auxiliary_device_init() before all fields used by bnxt_aux_dev_release() are initialized. After auxiliary_device_init() succeeds, later errors must unwind with auxiliary_device_uninit(), which invokes the release callback. The release callback assumes that aux_priv->id, aux_priv->edev, edev->net and edev->ulp_tbl are all populated. If allocation fails after auxiliary_device_init(), the release path can otherwise dereference or clear partially initialized state. Allocate and attach the bnxt_en_dev and ULP table before calling auxiliary_device_init(), so the release callback only sees a fully initialized auxiliary private object. If auxiliary_device_init() itself fails, free those allocations directly because device_initialize() has not run and the release callback will not be invoked. 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-68382", "url": "https://ubuntu.com/security/CVE-2026-68382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Hold device ref until queue teardown completes GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock. Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending. Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work. With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. Replace the fini wait with an assertion and remove the unused fini_wq. v2: - Rebase v3: - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt) - Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt) - Drop separate deferred drm_dev_put worker. - Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini(). v4: - Replace the guc_submit_sw_fini() wait with an assertion and remove the now-unused fini_wq. (sashiko) v5: - Move destroy work to a module-lifetime Xe workqueue instead of system_dfl_wq. (Matt) - Flush the module-lifetime destroy workqueue during PCI remove to preserve the old device-remove wait semantics. v6: - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid letting it outlive the xe_device/drm_device. (Sashiko) - Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work can be queued from the reclaim path. v7: - Drop the per-device xe->destroy_wq and use the module-level destroy WQ for SVM pagemap destroy as well. (Matt) - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*() helpers because the WQ is no longer exec-queue specific. (Matt) v8: - Rebase. v9: - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM destroy_wq because it can be queued from reclaim and embeds the dev_pagemap used by devres teardown. (Sashiko) - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM from it. - Update the module-WQ kdoc to document the GuC/SVM split. v10: - Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the workqueue allocation warning. v11: - Drop the SVM pagemap destroy comment as it was revision-specific. (Thomas) v12: - Rebase. (cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68383", "url": "https://ubuntu.com/security/CVE-2026-68383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Keep scheduler timeline name alive The scheduler keeps a pointer to the timeline name, but q->name is freed with the exec queue while scheduler fences can still reference it. Store the name in struct xe_guc_exec_queue so it shares the scheduler's RCU-deferred lifetime. (cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68390", "url": "https://ubuntu.com/security/CVE-2026-68390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups hci_conn_params_lookup requires hdev->lock be held, otherwise the list iteration or param access is not safe. Hold hdev->lock for params lookups in hci_sync.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-2026-68404", "url": "https://ubuntu.com/security/CVE-2026-68404", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: use wiphy work for socket owner autodisconnect nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68367", "url": "https://ubuntu.com/security/CVE-2026-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: synchronize delayed set_alt with teardown The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68095", "url": "https://ubuntu.com/security/CVE-2026-68095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse-uring: fix race between registration and connection abortion This fixes this race: - thread a: io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref yet - thread b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() is a no-op due to queue ref being 0 - thread a: grabs the queue_ref, queue_ref is now 1, rest of fuse_uring_do_register() logic executes - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs and calls \"wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);\" The abort/unmount thread will hang indefinitely in unkillable state as nothing will decrement queue_refs or wake stop_waitq, and the ring, queue, and ent are leaked. Fix this by checking fch->connected under fch->lock after the created ent has grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either release the queue ref and wake up stop_waitq (in case fuse_chan_wait_aborted() is already waiting) in fuse_uring_do_register() when we detect !fch->connected, or if the connection is aborted after the check, it is guaranteed that the async teardown worker will be running in the background cleaning up ents and decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-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-68173", "url": "https://ubuntu.com/security/CVE-2026-68173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: wait on ublk_dev_ready() instead of ub->completion ub->completion is only re-armed by a successful START_USER_RECOVERY. If the ublk server sends END_USER_RECOVERY without one - e.g. its START failed with -EBUSY and the error was ignored - the wait is satisfied by the stale completion of the previous recovery cycle, and the device is marked LIVE and the requeue list kicked while the FETCH stream is still running and ubq->canceling is still set. The kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it again via __ublk_abort_rq(), and after the last FETCH clears ->canceling nothing ever kicks the requeue list again: the request is stranded there while holding its tag. If it is the flush machinery's flush_rq, every subsequent fsync piles up in uninterruptible sleep and teardown hangs on tag draining. This matches a report of a lost PREFLUSH with ext4 on top of ublk after daemon crash recovery. ub->completion is an edge-triggered latch used as a proxy for the level condition \"every queue has fetched all I/O commands\", which can regress (F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop it and wait on the real condition instead: the new helper ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then re-checks it under ub->mutex, waiting again on regression, and returns with the mutex held and readiness guaranteed. Readiness becomes true in the same ub->mutex critical section that clears the last queue's ->canceling, so END_USER_RECOVERY marks the device LIVE and kicks the requeue list strictly after ->canceling clears. The wait stays interruptible, so a server whose daemon died can still be signalled out. For ublk_ctrl_start_dev() this replaces the fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting until the device is ready again.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68113", "url": "https://ubuntu.com/security/CVE-2026-68113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68118", "url": "https://ubuntu.com/security/CVE-2026-68118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: challenge ACK for non-exact RST in SYN-RECEIVED The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68120", "url": "https://ubuntu.com/security/CVE-2026-68120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtase: Workaround for TX hang caused by hardware packet parsing The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission.", "cve_priority": "medium", "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-68122", "url": "https://ubuntu.com/security/CVE-2026-68122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix peer refcount leak in TCP error paths When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&peer->tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object. The race window: CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error): ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2 schedule_work() <- queued schedule_work() <- NO-OP (work already pending) ovpn_tcp_peer_del_work runs: ovpn_peer_del() ovpn_peer_put() <- refcnt+1 <- peer never freed Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68128", "url": "https://ubuntu.com/security/CVE-2026-68128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: reject out-of-range ptype in ice_parser_profile_init set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from providing ptype >= 1024 through VIRTCHNL, resulting in a write past the end of the bitmap and a kernel page fault. Reproduced with a custom kernel module injecting a crafted VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1. crash_parser: ice_parser_profile_init @ ffffffffc0d61b60 crash_parser: setting ptype=0xffff (max valid=1023) crash_parser: calling ice_parser_profile_init -- expect OOB crash! BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace: ? __pfx_ice_parser_profile_init+0x10/0x10 [ice] crash_init+0x127/0xff0 [crash_parser] do_one_initcall+0x45/0x310 do_init_module+0x64/0x270 init_module_from_file+0xcc/0xf0 idempotent_init_module+0x17b/0x280 __x64_sys_finit_module+0x6e/0xe0 Bail out early with -EINVAL when ptype is out of range.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68132", "url": "https://ubuntu.com/security/CVE-2026-68132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: super: fix emergency thaw deadlock on frozen block devices do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68133", "url": "https://ubuntu.com/security/CVE-2026-68133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP Call Trace during PTP release If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will result in the following PTP release call trace during driver unload: kernel BUG at lib/list_debug.c:52! ice_ptp_release+0x332/0x3c0 [ice] ice_deinit_features.part.0+0x10e/0x120 [ice] ice_remove+0x100/0x220 [ice] This was observed when passing PF1 through to a VM. ice_ptp_init() fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT. Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and returning without error, preventing the invalid state transition to ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from ICE_PTP_RESETTING after a failed rebuild.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68134", "url": "https://ubuntu.com/security/CVE-2026-68134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: ptp_s390: Add missing facility check Only register the physical clock when facility 28 is installed and PTFF QAF returns that PTFF QPT is available.", "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-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-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-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-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-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-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-68150", "url": "https://ubuntu.com/security/CVE-2026-68150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/super: fix emergency thaw double-unlock of s_umount do_thaw_all() iterates over all superblocks via __iterate_supers() with SUPER_ITER_EXCL, which acquires s_umount exclusively before calling the callback and releases it afterwards. However, the callback do_thaw_all_callback() calls thaw_super_locked() which unconditionally releases s_umount on every code path. This results in a second unlock attempt in __iterate_supers() that corrupts the rwsem state, triggering a DEBUG_RWSEMS warning: [ 182.601148] sysrq: Emergency Thaw of all frozen filesystems [ 182.601865] ------------[ cut here ]------------ [ 182.602375] DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff99b1011e5870, owner = 0x0, curr 0xffff99b101b06c80, list not empty [ 182.603817] WARNING: kernel/locking/rwsem.c:1412 at up_write+0xa3/0x170, CPU#2: kworker/2:1/53 [ 182.604578] Modules linked in: [ 182.604864] CPU: 2 UID: 0 PID: 53 Comm: kworker/2:1 Not tainted 7.2.0-rc4-00001-gbd3bd93ea98a-dirty #4 PREEMPT(lazy) [ 182.605711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014 [ 182.606417] Workqueue: events do_thaw_all [ 182.606750] RIP: 0010:up_write+0xaf/0x170 [ 182.607076] Code: 19 3a 92 48 0f 44 c2 48 8b 55 08 48 8b 55 00 4c 8b 45 08 48 8b 55 00 48 8d 3d ad 91 e0 01 48 8b 4d 20 50 48 c7 c6 f0 8c 26 92 <67> 48 0f b9 3a e8 d7 93 4e 00 58 eb 81 48 83 7f 18 00 48 c7 c2 8d [ 182.608563] RSP: 0018:ffffb670001d7e08 EFLAGS: 00010246 [ 182.609007] RAX: ffffffff92349e8d RBX: 0000000000000000 RCX: ffff99b1011e5870 [ 182.609595] RDX: 0000000000000000 RSI: ffffffff92268cf0 RDI: ffffffff92914d10 [ 182.610283] RBP: ffff99b1011e5870 R08: 0000000000000000 R09: ffff99b101b06c80 [ 182.610847] R10: ffff99b10139a808 R11: fefefefefefefeff R12: 0000000000000000 [ 182.611414] R13: ffffffff90cf74d0 R14: 0000000000000000 R15: ffff99b1011e5800 [ 182.612009] FS: 0000000000000000(0000) GS:ffff99b1eaaee000(0000) knlGS:0000000000000000 [ 182.612670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 182.613146] CR2: 00000000005c631c CR3: 00000000013ee000 CR4: 00000000000006f0 [ 182.613722] Call Trace: [ 182.613946] [ 182.614130] __iterate_supers+0x128/0x150 [ 182.614463] do_thaw_all+0x1b/0x30 [ 182.614759] process_scheduled_works+0xbb/0x3f0 [ 182.615150] ? __pfx_worker_thread+0x10/0x10 [ 182.615499] worker_thread+0x129/0x270 [ 182.615816] ? __pfx_worker_thread+0x10/0x10 [ 182.616201] kthread+0xe2/0x120 [ 182.616469] ? __pfx_kthread+0x10/0x10 [ 182.616792] ret_from_fork+0x15b/0x240 [ 182.617115] ? __pfx_kthread+0x10/0x10 [ 182.617426] ret_from_fork_asm+0x1a/0x30 [ 182.617761] [ 182.617968] ---[ end trace 0000000000000000 ]--- [ 182.618412] Emergency Thaw complete Fix this by switching to SUPER_ITER_UNLOCKED and acquiring s_umount in the callback via super_lock_excl() before calling thaw_super_locked(). This matches the locking pattern expected by thaw_super_locked() and eliminates the double unlock. While at it, remove the dead 'return;' at the end of do_thaw_all_callback().", "cve_priority": "low", "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-68152", "url": "https://ubuntu.com/security/CVE-2026-68152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: fix use-after-free in AMT delayed works When an AMT device is removed, pending delayed works can still access the freed amt_dev structure, which may result in kernel crashes or memory corruption. amt_dev_stop() cancels req_wq and discovery_wq with cancel_delayed_work_sync(), but these works can be scheduled again from event_wq after the cancellation. This allows delayed works to access the freed amt_dev structure after the netdev has been released. The following is a simple race scenario: CPU0 CPU1 amt_dev_stop() cancel_delayed_work_sync() amt_event_work() mod_delayed_work(req_wq) free netdev req_wq accesses freed amt_dev Use disable_delayed_work_sync() in amt_dev_stop() to prevent req_wq and discovery_wq from being queued again and wait for running work items to complete. The delayed works are disabled after initialization in amt_newlink() and enabled only when the device is successfully opened. This keeps the delayed work lifecycle synchronized with the lifetime of the AMT device.", "cve_priority": "high", "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-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-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-68168", "url": "https://ubuntu.com/security/CVE-2026-68168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix afs_edit_dir_remove() to get, not find, block 0 Fix afs_edit_dir_remove() to use afs_dir_get_block() to get block 0 rather than afs_dir_find_block() as the latter caches the found block in the afs_dir_iter and may[*] switch out the page it's on if another afs_dir_find_block() is done. This parallels what afs_edit_dir_add() does. [*] There's more than one block per page.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68169", "url": "https://ubuntu.com/security/CVE-2026-68169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: userspace: fix use-after-free in get_local_id In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a \"not found\" sentinel.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68172", "url": "https://ubuntu.com/security/CVE-2026-68172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: make huge_ptep_get handled unaligned addresses huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma). The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned. On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map or into a hole, dereference a VA not mapped into the kernel pgtables and cause kernel panic. Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68174", "url": "https://ubuntu.com/security/CVE-2026-68174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix union collision of module and refcnt for dynamic events In 'struct trace_event_call', the 'module' pointer and the 'refcnt' atomic variable share the same memory space in a union. For dynamic events, the union member is 'refcnt', which acts as an active reference counter. When a dynamic event (such as kprobe, uprobe, fprobe, eprobe, or wprobe) has a non-zero reference count (e.g. due to active event triggers or perf attachments), its 'call->module' evaluates to a small non-zero integer instead of NULL. When filtering or setting events for a specific module (e.g., writing ':mod:' to 'set_event'), the code in '__ftrace_set_clr_event_nolock()' and 'update_event_fields()' reads 'call->module' directly without checking whether the event is dynamic. This causes the kernel to treat the small integer (refcnt) as a 'struct module' pointer, leading to a NULL/invalid pointer dereference (Oops) when dereferencing the module name. Fix this by ensuring that the 'TRACE_EVENT_FL_DYNAMIC' flag is checked before treating 'call->module' as a valid pointer in these code paths.", "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-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-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-68434", "url": "https://ubuntu.com/security/CVE-2026-68434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms Commit b1b4efea05a5 (\"serial: 8250_mid: Disable DMA for selected platforms\") replaced the dnv_board setup and exit callbacks with PTR_IF(false, ...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. Fix this by adding the missing NULL checks before calling the setup and exit callbacks.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17: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-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-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16: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-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-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-68198", "url": "https://ubuntu.com/security/CVE-2026-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix use-after-free in aggr_reset_state() The aggr_reset_state() function uses timer_delete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggr_module_destroy(). If the timer callback (aggr_timeout) is executing when aggr_reset_state() is called, the callback will continue to access aggr_conn fields like rx_tid[] and stat[] which may be freed immediately after by kfree(aggr_info->aggr_conn) in aggr_module_destroy(). Additionally, the timer callback can re-arm itself via mod_timer() while aggr_reset_state() is running, creating a more complex race condition. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "high", "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-68200", "url": "https://ubuntu.com/security/CVE-2026-68200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: don't re-enter an instance callback that is still running The userspace-driven timer (utimer) TRIGGER ioctl calls snd_timer_interrupt() directly with no serialization, so two threads triggering the same utimer can run snd_timer_interrupt() on one snd_timer concurrently. snd_timer_process_callbacks() drops timer->lock around each instance callback and marks the in-flight callback with the single SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that bit to drain an in-flight callback before freeing the instance. The bit cannot represent two concurrent callbacks: when a second interrupt re-queues an instance whose callback is still running, both run at once, the first to finish clears the bit, and the close-path drain then frees the instance (and its callback_data) while the other callback is still live - a use-after-free reachable by any user able to open /dev/snd/timer, both via a user timer instance and via a sequencer queue timer bound to the utimer. snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so a concurrent interrupt already observes it under the lock. Skip re-queuing an instance (and its slaves) to the ack/sack list while its callback is in flight; the accumulated pticks are delivered on the next tick, so no event is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68201", "url": "https://ubuntu.com/security/CVE-2026-68201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: drain a slave's callback before its master detaches it snd_timer_close_locked() drains the closing instance's own in-flight callback (IFLG_CALLBACK) before freeing it, but not its slaves'. When a master instance is closed, remove_slave_links() clears each slave's ->timer; the slave's own close then reads timer == NULL and takes the branch that skips the drain entirely (snd_timer_stop_slave() also no-ops on a NULL timer). So a slave whose callback is still running when the master is closed is freed underneath the live callback, leading to use-after-free. Drain the slaves too before remove_slave_links() severs them. snd_timer_stop() has already taken this instance off the active list, so no new slave callback can be queued. Take the slaves off the ack list so a pending one can't fire either, then wait for any that is already in flight.", "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-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-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-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-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-68211", "url": "https://ubuntu.com/security/CVE-2026-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32-dcmipp: 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. dcmipp_bytecap_start_streaming() returned -EINVAL when the source subdevice could not be resolved from the media graph, before pm_runtime_resume_and_get() and media_pipeline_start() had been called. The remaining error paths already converge on the err_buffer_done label, which calls dcmipp_bytecap_all_buffers_done(..., VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate err_pm_put / err_media_pipeline_stop 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": "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-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-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-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-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-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-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-68230", "url": "https://ubuntu.com/security/CVE-2026-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: amlogic-c3: Add validations for ae and awb config Avoid invalid memory access if the zones_num is bigger than zone_weight. This patch fixes the following smatch errors: drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max", "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-68232", "url": "https://ubuntu.com/security/CVE-2026-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path.", "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-68233", "url": "https://ubuntu.com/security/CVE-2026-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Shut down BO cache timer before teardown The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20: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-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-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-68238", "url": "https://ubuntu.com/security/CVE-2026-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Release VFCT ACPI table reference amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68239", "url": "https://ubuntu.com/security/CVE-2026-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Account for NULL and handle pages in ttm_pool_backup Pages in ttm_pool_backup can be NULL or backup handles (ttm_backup_page_ptr_is_handle()), neither of which can be passed to set_pages_array_wb() or freed. Add a dedicated WB pass before the dma/purge loop that walks allocations using the same i += num_pages stride, skipping NULL and handle entries, and calls set_pages_array_wb() once per contiguous run of real pages. Apply the same NULL/handle guard to the dma/purge loop. Fixes the following oops: Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI RIP: 0010:__cpa_process_fault+0xf8/0x770 RSP: 0018:ffffc90000a87718 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34 RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0 R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000 R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0 FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0 PKRU: 55555554 Call Trace: __change_page_attr_set_clr+0x989/0xe90 ? __purge_vmap_area_lazy+0x6c/0x3a0 ? _vm_unmap_aliases+0x250/0x2a0 set_pages_array_wb+0x7f/0x120 ttm_pool_backup+0x4c9/0x5b0 [ttm] ? dma_resv_wait_timeout+0x3b/0xf0 ttm_tt_backup+0x32/0x60 [ttm] ttm_bo_shrink+0x66/0x110 [ttm] xe_bo_shrink_purge+0x12b/0x1b0 [xe] xe_bo_shrink+0xbb/0x270 [xe] __xe_shrinker_walk+0xf7/0x160 [xe] xe_shrinker_walk+0x9d/0xc0 [xe] xe_shrinker_scan+0x11f/0x210 [xe] do_shrink_slab+0x13b/0x270 shrink_slab+0xf1/0x400 shrink_node+0x352/0x8a0 balance_pgdat+0x32c/0x700 kswapd+0x205/0x2f0 ? __pfx_autoremove_wake_function+0x10/0x10 ? __pfx_kswapd+0x10/0x10 kthread+0xd1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1b1/0x200 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68241", "url": "https://ubuntu.com/security/CVE-2026-68241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/mst: limit DP MST ESI service loop The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto. (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)", "cve_priority": "medium", "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-68245", "url": "https://ubuntu.com/security/CVE-2026-68245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only valid while the lock is still being held. Once xa_unlock_irqrestore is called and returned, the pointer is no longer under lock and is subject to modification. Since, the caller still dereferences vm->task_info in amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a use after unlock problem. Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid() through removing the amdgpu_vm_get_vm_from_pasid() function from amdgpu_vm.c and making the relevant code inline to hold the lock while it is still in use. (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)", "cve_priority": "high", "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-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-68252", "url": "https://ubuntu.com/security/CVE-2026-68252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68253", "url": "https://ubuntu.com/security/CVE-2026-68253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)", "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-68257", "url": "https://ubuntu.com/security/CVE-2026-68257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix 32-bit overflow in CWSR total size calculation total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68258", "url": "https://ubuntu.com/security/CVE-2026-68258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on CRIU restore queue type and mqd size We weren't checking whether the values provided in the private data in kfd CRIU restore were within bounds. For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it. For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations. (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)", "cve_priority": "low", "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-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-68266", "url": "https://ubuntu.com/security/CVE-2026-68266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68268", "url": "https://ubuntu.com/security/CVE-2026-68268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Return error on non-migratable faults requiring devmem Non-migratable faults that require devmem incorrectly jump to the 'out' label, which squashes the error code intended to be returned to the upper layers. Fix this by returning -EACCES instead. (cherry picked from commit c4508edb2c723de93717272488ea65b165637eac)", "cve_priority": "medium", "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-68270", "url": "https://ubuntu.com/security/CVE-2026-68270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Avoid possible truncation with calculating visible size Calculating the visible size of the system framebuffer can result in truncation of the result. The calculation uses 32-bit arithmetics, which can overflow if the values for height and stride are large. Fix the issue by multiplying with mul_u32_u32().", "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-68275", "url": "https://ubuntu.com/security/CVE-2026-68275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks up the bo_va for the buffer object in the caller's VM via amdgpu_vm_bo_find(), but uses the returned pointer without checking it. amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM, which is the normal case for a BO that has never been mapped. The result is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which expands to list_for_each_entry(mapping, &(bo_va)->valids, list) and dereferences bo_va, causing a NULL pointer dereference. This is reachable by any process able to issue the ioctl (render group) simply by requesting mapping info for an unmapped BO. Return -ENOENT when no bo_va is found, jumping to out_exec so the drm_exec context and GEM object reference are released. (cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68276", "url": "https://ubuntu.com/security/CVE-2026-68276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx: fix cleaner shader IB buffer overflow The cleaner shader sysfs path allocates a 16-dword (64 byte) IB but incorrectly fills (align_mask + 1) dwords. On GFX rings align_mask is 0xff, so the loop wrote 256 dwords into a 64-byte buffer, causing a kernel page fault. The IB only needs to be a minimal NOP shell to schedule the job; the cleaner shader itself is emitted on the ring via emit_cleaner_shader(). Fill 16 dwords to match the allocation. v2: Use ib_size_dw variable (Lijo) (cherry picked from commit bf21af331ebf72d0935fd70c73192414a422c03a)", "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-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-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-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-68282", "url": "https://ubuntu.com/security/CVE-2026-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: analogix_dp: Add missing error check for platform_get_resource() Add missing error check for platform_get_resource() return value to prevent NULL pointer dereference when memory resource is not available.", "cve_priority": "medium", "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-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-68292", "url": "https://ubuntu.com/security/CVE-2026-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues.", "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-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-68296", "url": "https://ubuntu.com/security/CVE-2026-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM Before commit 00d066a4d4ed (\"netdev_features: convert NETIF_F_LLTX to dev->lltx\"), NETIF_F_LLTX was set unconditionally in both __gre_tunnel_init() and ip6gre_tnl_init_features() alongside GRE_FEATURES: dev->features |= GRE_FEATURES | NETIF_F_LLTX; When that commit converted NETIF_F_LLTX to the dev->lltx flag, it placed 'dev->lltx = true' after the SEQ/CSUM early returns instead of before them. This causes GRE/GRETAP/ip6gre tunnels with SEQ or CSUM+encap to lose lockless TX, reintroducing _xmit_lock acquisition around their ndo_start_xmit. Since GRE xmit re-enters the stack via ip_tunnel_xmit(), holding _xmit_lock risks ABBA deadlock with the underlay device. CPU0 CPU1 ---- ---- lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); Fix by moving dev->lltx = true before the early returns in both functions, restoring the original unconditional behavior.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64575", "url": "https://ubuntu.com/security/CVE-2026-64575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: fix double sock release on batch realloc bpf_iter_tcp_batch() releases the current batch via bpf_iter_tcp_put_batch(), which drops the socket refs and rewrites each slot with the socket cookie, then grows the batch. cur_sk/end_sk are kept for bpf_iter_tcp_resume(), but on realloc failure the function returns ERR_PTR() before resume runs, leaving cur_sk < end_sk over slots that now hold cookies rather than sock pointers. bpf_iter_tcp_seq_stop() then calls bpf_iter_tcp_put_batch() again and dereferences a cookie as a struct sock. Empty the batch on the failure path so stop() does not release it again. The sockets were already freed by the first bpf_iter_tcp_put_batch(), so nothing leaks, and a later read() rescans the bucket from the start instead of skipping it. The sibling GFP_NOWAIT failure path still holds real socket references and is left for stop() to release. BUG: KASAN: null-ptr-deref in __sock_gen_cookie Read of size 8 at addr 0000000000000059 by task exploit ... __sock_gen_cookie (net/core/sock_diag.c:28) bpf_iter_tcp_put_batch (net/ipv4/tcp_ipv4.c:2918) bpf_iter_tcp_seq_stop (net/ipv4/tcp_ipv4.c:3270) bpf_seq_read (kernel/bpf/bpf_iter.c:205) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 entry_SYSCALL_64_after_hwframe Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68298", "url": "https://ubuntu.com/security/CVE-2026-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create() Commit 9e9787414882 (\"drm/xe/userptr: replace xe_hmm with gpusvm\") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a \"simple\" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). (cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4)", "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-68448", "url": "https://ubuntu.com/security/CVE-2026-68448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: check access to copy_file_range source with src mounter creds Commit 5dae222a5ff0c (\"vfs: allow copy_file_range to copy across devices\") allowed filesystems that implement the copy_file_range() f_op to decide if they want to access cross-sb copy from/to the same fs type. The same commit added checks to verify same sb copy for filesystems that implement ->copy_file_range() and do not support cross-sb copy at the time, namely, to ceph, fuse and nfs. The two remaining fs which implement ->copy_file_range(), cifs and overlayfs started to support cross-sb copy from this time. While overlayfs does support cross-sb copy when the two underlying files are on the same base fs, the copy operation on the two real files from two different overalyfs filesystems is performed with the mounter creds of the destination overlayfs and the read permission access hook for the source file was called with the wrong creds. This could cause either deny of access to copy which would otherwise be allowed (e.g. with splice) or allow read access to file which would otherwise be denied. Fix the latter case by explicitly verifying read access to source file with the source overlayfs mounter creds. The former case remains a quirk of cross-sb overlayfs copy, but userspace could fall back to regular copy so no harm done.", "cve_priority": "low", "cve_public_date": "2026-08-12 01:17: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-68307", "url": "https://ubuntu.com/security/CVE-2026-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix crash in reset link replay During reset recovery, mt7925_vif_connect_iter() replays firmware state for links tracked in mvif->valid_links. After MLO link changes or MCU timeout recovery, the driver bitmap can temporarily contain a link whose mac80211 bss_conf has already gone away. This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching the crash where x1, the second argument, is NULL: pc : mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] lr : mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] x2 : ffffff80a77f6018 x1 : 0000000000000000 x0 : ffffff8099402080 Call trace: mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common] Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA reset replay is unchanged because the helper still returns &vif->bss_conf for the legacy link.", "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-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-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-68311", "url": "https://ubuntu.com/security/CVE-2026-68311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: guard link STA in decap offload mt7925_sta_set_decap_offload() iterates over the vif valid_links mask when updating decap offload state for an MLO station. The station may not have a link STA for every valid link of the vif, so mt792x_sta_to_link() can return NULL for a link that belongs to the vif but not to the station. The function currently dereferences mlink before checking whether the link WCID is ready. If mlink is NULL, setting or clearing MT_WCID_FLAG_HDR_TRANS dereferences a NULL pointer. Skip links without a station link before touching mlink->wcid.", "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-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-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-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-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-68321", "url": "https://ubuntu.com/security/CVE-2026-68321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix FDIR filter leak on remove Perfect FDIR filters can be added while the interface is down and are kept on the software list for later restore. unregister_netdev() only calls ndo_stop when the device is up, so txgbe_fdir_filter_exit() in txgbe_close() is skipped in that case and the filters are leaked on driver remove. Free the filter list from txgbe_remove() as well.", "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-68330", "url": "https://ubuntu.com/security/CVE-2026-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix DMA direction for NPU mailbox buffer airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE, but some callers expect the NPU to write response data back into the same buffer: - airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into the buffer, then the caller reads it via memcpy() - airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back npu_stats_addr field in the response On non-cache-coherent architectures like EN7581 (Cortex-A53 without hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op — it does not invalidate the CPU cache. If the NPU-written cache line is still present in the CPU cache when the caller reads the buffer, the CPU observes stale data instead of the NPU response. This is a timing-sensitive bug: small mailbox buffers (~24 bytes) typically fit in a single cache line and may survive in the cache until the caller reads them, producing silent data corruption rather than a crash. The bug is more likely to trigger when the caller reads the response immediately after dma_unmap_single() without intervening cache-evicting operations. Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures dma_unmap_single() invalidates the CPU cache on non-coherent systems. The mailbox buffers are small so there is no performance concern.", "cve_priority": "low", "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-68332", "url": "https://ubuntu.com/security/CVE-2026-68332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix potential use-after-free in airoha_ppe_deinit() airoha_ppe_deinit() replaces the NPU pointer with NULL via rcu_replace_pointer() but does not wait for existing RCU readers to exit before calling ppe_deinit() and airoha_npu_put(). This can cause a use-after-free if a reader in an RCU read-side critical section still holds a reference to the NPU when it is freed. The init path (airoha_ppe_init) already calls synchronize_rcu() after rcu_assign_pointer(), but the deinit path introduced in commit 6abcf751bc08 (\"net: airoha: Fix schedule while atomic in airoha_ppe_deinit()\") omitted the matching barrier when switching from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer(). Add synchronize_rcu() before ppe_deinit() to ensure all existing RCU readers have completed before the NPU resources are released.", "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-68334", "url": "https://ubuntu.com/security/CVE-2026-68334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix io_thread race in rxrpc_wake_up_io_thread() rxrpc_wake_up_io_thread() checks local->io_thread before waking it, but then reloads the pointer for wake_up_process(). local->io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so the second load can see NULL even if the first load did not. Take a READ_ONCE() snapshot and use it for both the NULL check and the wake_up_process() call, as rxrpc_encap_rcv() already does.", "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-68341", "url": "https://ubuntu.com/security/CVE-2026-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix use after free in unlock_ovpn() unlock_ovpn() iterates over the release_list using llist_for_each_entry() and drops the peer reference inside the loop body via ovpn_peer_put(). If this drops the last reference, the peer is eventually freed. However, llist_for_each_entry() reads peer->release_entry.next in the loop advance expression, which runs after the body. By that time the peer may have already been freed, resulting in a use after free when advancing to the next list entry. Fix this by using llist_for_each_entry_safe(), which caches the next pointer before executing the loop body.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68342", "url": "https://ubuntu.com/security/CVE-2026-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: avoid putting unrelated P2P peer on socket release ovpn_peer_release_p2p() is called when an OVPN UDP socket is being destroyed. It checks the currently published P2P peer and releases it only if that peer still uses the socket being destroyed. A peer replacement can publish a new peer before the old UDP socket is destroyed. When the old socket destruction path runs afterwards, ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the new peer uses a different socket, the function takes the socket mismatch branch. That branch still calls ovpn_peer_put(peer). At this point, however, peer is the currently published replacement peer, not the peer associated with the socket being destroyed. Dropping its reference can free it while ovpn->peer still points to it, leading to later use-after-free accesses from the peer and socket cleanup paths. KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer object. In the reproducer, the object is allocated from ovpn_peer_new() via ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU callback processing. Observed access sites include ovpn_peer_remove(), ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn(). Fix this by returning from the socket mismatch branch without putting the peer.", "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-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-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-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-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-68356", "url": "https://ubuntu.com/security/CVE-2026-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: airoha: Prevent division by zero when clock frequency is zero clk_get_rate() can return 0 when the clock provider is not properly configured or the clock is unmanaged. The driver uses wdt_freq as a divisor directly in airoha_wdt_probe() to compute max_timeout and in airoha_wdt_get_timeleft() to compute the remaining time, which results in a division by zero. Add a check for wdt_freq == 0 in probe and return -EINVAL with dev_err_probe() to prevent the division by zero and provide a diagnostic message.", "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-68358", "url": "https://ubuntu.com/security/CVE-2026-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-kraken3) 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-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-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-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-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-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-68374", "url": "https://ubuntu.com/security/CVE-2026-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: sysfs: add lock to bos_descriptors_read() Add a lock to the function bos_descriptors_read(). This function accesses udev->bos, which could be simultaneously freed in usb_reset_and_verify_device(), a function that is commonly called in drivers all over the kernel.", "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-68378", "url": "https://ubuntu.com/security/CVE-2026-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions: - A pin is registered with two or more dpll devices (dpll_A, dpll_B) - The pin has ref_sync pairs with other pins - During unregistration of dpll_A's pins, a ref_sync partner pin is unregistered first, removing it from dpll_A->pin_refs - But since the partner pin is still registered with dpll_B, its dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT run and the partner stays in the pin's ref_sync_pins xarray - When the pin itself is then unregistered from dpll_A, the delete notification calls dpll_msg_add_pin_ref_sync() which finds the partner in ref_sync_pins, passes dpll_pin_available() (partner is still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A, partner) returns NULL because partner was already removed from dpll_A->pin_refs - The NULL priv pointer is passed to the driver's ref_sync_get callback, which dereferences it BUG: kernel NULL pointer dereference, address: 0000000000000034 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x] Call Trace: dpll_msg_add_pin_ref_sync+0xb8/0x200 dpll_cmd_pin_get_one+0x3b6/0x4b0 dpll_pin_event_send+0x72/0x140 __dpll_pin_unregister+0x5a/0x2b0 dpll_pin_unregister+0x49/0x70 Fix this by skipping ref_sync pins whose priv pointer cannot be resolved for the current dpll device.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68379", "url": "https://ubuntu.com/security/CVE-2026-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix TIME_WAIT socket reference leak on PSP policy failure Release the TIME_WAIT socket reference and jump to discard_it upon PSP policy failure in both IPv4 and IPv6 receive paths. This prevents a memory leak of tcp_tw_bucket structures.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68380", "url": "https://ubuntu.com/security/CVE-2026-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix use-after-free of mm_struct in job scheduler amdxdna_cmd_submit() stores current->mm in job->mm without holding any reference. aie2_sched_job_run() later access job->mm from the DRM scheduler worker thread. With only a raw pointer and no structural reference, the mm_struct can be freed before the scheduler runs the job. Fix this by calling mmgrab() to hold a structural mm_count reference for the lifetime of the job, paired with mmdrop() in every cleanup path.", "cve_priority": "high", "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-68384", "url": "https://ubuntu.com/security/CVE-2026-68384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits. - Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it. While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one. (cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68385", "url": "https://ubuntu.com/security/CVE-2026-68385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/checksum: Fix csum_partial() without vector facility Currently csum_partial() calls csum_copy() with copy=false and dst=NULL. On machines without the vector facility, csum_copy() falls back to cksm(dst, ...), causing the checksum to be calculated from address zero instead of the source buffer. The VX implementation already checksums data loaded from src. Make the fallback do the same by passing src to cksm().", "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-68387", "url": "https://ubuntu.com/security/CVE-2026-68387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: add locking for raw flags bitfield With commit 890e5198a6e5 (\"can: raw: use bitfields to store flags in struct raw_sock\") the formerly separate integer values have been integrated into a single bitfield. This led to a read-modify-write operation when changing a flag in raw_setsockopt() which now needs a locking to prevent concurrent access. Instead of adding a lock/unlock hell in each of the flag manipulations this patch introduces a wrapper for a new raw_setsockopt_locked() function analogue to the isotp_setsockopt[_locked]() approach in net/can/isotp.c [mkl: use Closes tag instead of Link]", "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-68393", "url": "https://ubuntu.com/security/CVE-2026-68393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: extend conn_hash lookup critical sections Using RCU-protected pointers outside the critical sections without refcount is incorrect and may result to UAF. Extend critical section to cover both hci_conn_hash lookup and use of the returned conn. Add surrounding rcu_read_lock() also when return value is not used, in preparation for RCU lockdep requirement to hci_lookup_le_connect(). This avoids concurrent deletion of the conn before we are done dereferencing it. Also, make sure to hold hdev->lock when accessing hdev->accept_list.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68394", "url": "https://ubuntu.com/security/CVE-2026-68394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update MGMT_OP_LOAD_CONN_PARAM queues conn_update_sync() when a single parameter update changes an existing LE central connection. The queued work currently stores a borrowed hci_conn_params entry from hdev->le_conn_params. A later LOAD_CONN_PARAM request can clear disabled parameters and free that entry before hci_cmd_sync_work() runs the queued callback. Do not keep the borrowed hci_conn_params pointer in queued work. Queue the hci_conn instead and hold a reference until the queued callback completes. When the work runs, revalidate that the connection is still present, look up the current hci_conn_params entry, and cancel the update if userspace removed that entry while the work was pending. Copy the interval values from the current params entry under hdev->lock, then drop the lock and keep using hci_le_conn_update_sync() to issue the update. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in conn_update_sync+0x2a/0xf0 [bluetooth] Read of size 1 at addr ffff88810c697126 by task kworker/u17:0/377 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 kasan_report+0xe0/0x110 conn_update_sync+0x2a/0xf0 [bluetooth] hci_cmd_sync_work+0x187/0x210 [bluetooth] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 Allocated by task 466: hci_conn_params_add+0xa6/0x240 [bluetooth] load_conn_param+0x4e1/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] Freed by task 474: kfree+0x313/0x590 hci_conn_params_clear_disabled+0x9b/0xc0 [bluetooth] load_conn_param+0x4bf/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth]", "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-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-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-68400", "url": "https://ubuntu.com/security/CVE-2026-68400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint memory access array and to comply with the FF-A spec instead of defaulting to `sizeof(struct ffa_mem_region)`. This requires moving `ffa_mem_region_additional_setup()` earlier in the setup flow. Also, add sanity checks to ensure the calculated descriptor offsets do not exceed `max_fragsize`.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68401", "url": "https://ubuntu.com/security/CVE-2026-68401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() Sashiko (locally) reports multiple out-of-bound issues in ffa_setup_and_transmit: 1) Writing ep_mem_access->reserved can write out of bounds for FFA versions < 1.2 as ffa_emad_size_get() returns 16 bytes in that case while reserved has an offset of 24. Instead of zeroing fields, memset the struct to zero first based on the FFA version. 2) Make sure there is enough size to write constituents. While at it, convert the only sizeof() in the driver that uses a type instead of variable.", "cve_priority": "high", "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-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-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-68409", "url": "https://ubuntu.com/security/CVE-2026-68409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: defer link RX stats percpu free to RCU sta_remove_link() frees a removed MLO link's RX stats percpu buffer right away, but defers only the link container to RCU: \tsta_info_free_link(&alloc->info); \tkfree_rcu(alloc, rcu_head); The RX fast path reads link_sta under rcu_read_lock and writes the percpu stats. A reader that resolved link_sta before the removal keeps the pointer. The container stays alive from the kfree_rcu, so the read still works. But the percpu block it points to is already freed. This needs uses_rss. That is when pcpu_rx_stats exists. The full STA teardown frees the deflink stats only after synchronize_net(). The link removal path had no such barrier. The race is hard to win in practice, but the free should still wait for RCU. Free the link together with its data from a single RCU callback, so the percpu block is reclaimed only after readers drain.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20: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-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-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-68412", "url": "https://ubuntu.com/security/CVE-2026-68412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan() If the test against IEEE80211_MAX_SSID_LEN fails, then 'creq' leaks. Use the existing error handling path to fix it.", "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-64566", "url": "https://ubuntu.com/security/CVE-2026-64566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags() When iptfs_skb_add_frags() copies frag references from the source frag walk into a new SKB, it increments the page reference count via __skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the destination SKB's skb_shinfo->flags. If the source SKB carries shared frags (e.g. from a page-pool backed receive path), the new inner SKB will appear to ESP as having privately owned frags. A subsequent esp_input() call for a nested transport-mode SA then takes the no-COW fast path and decrypts in place, writing over pages that are still referenced by the outer IPTFS SKB. This causes kernel-visible memory corruption and can trigger a panic. All other frag-transfer helpers in the kernel (skb_try_coalesce, skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this convention by setting the flag inside the loop immediately after __skb_frag_ref() and nr_frags++, so every exit path that attaches a frag unconditionally propagates SKBFL_SHARED_FRAG.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68415", "url": "https://ubuntu.com/security/CVE-2026-68415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear mode callbacks after failed mode setup xfrm_state_gc_task can run long after a failed IPTFS state setup. In the reproduced case, __xfrm_init_state() cached x->mode_cbs, IPTFS setup returned -ENOMEM before publishing mode_data, and the temporary module reference from xfrm_get_mode_cbs() was dropped immediately. The dead state then kept x->mode_cbs until deferred GC ran after xfrm_iptfs had been unloaded. Clear x->mode_cbs when mode init or clone fails before publishing mode_data. Those states never installed mode-specific state or the long-term IPTFS module pin, so deferred GC has nothing mode-specific to destroy and must not retain a callback table pointer past the temporary lookup reference. The buggy scenario involves two paths, with each column showing the order within that path: failed setup path: 1. cache x->mode_cbs 2. mode setup fails before mode_data 3. drop the temporary module ref 4. dead state keeps x->mode_cbs cached GC/unload path: 1. xfrm_state_put() queues GC work 2. xfrm_iptfs unloads later 3. xfrm_state_gc_task runs 4. GC dereferences stale x->mode_cbs This also covers the failed clone path where clone_state() returns before publishing mode_data. Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y failslab_stacktrace_filter matched xfrm_iptfs frames ack_error=-12 FAULT_INJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrm_state_gc_task RIP: xfrm_state_gc_task+0x142/0x650 Modules linked in: esp4_offload xfrm_user [last unloaded: xfrm_iptfs] Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68418", "url": "https://ubuntu.com/security/CVE-2026-68418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent user-triggered null deref on QP create Previously, the user QP creation path would only attempt to populate iwqp->iwpbl if the user-provided req.user_wqe_bufs field was non-zero. The problem is that iwqp->iwpbl is unconditionally dereferenced later on in irdma_setup_virt_qp. While there was a check for iwqp->iwpbl != NULL, this check would only occur if req.user_wqe_bufs was non-zero. The end result is that a user could send a zero user_wqe_bufs value and trigger a null ptr deref. Fix this by unconditionally calling irdma_get_pbl and bailing if it fails, similar to the CQ and SRQ paths.", "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-68420", "url": "https://ubuntu.com/security/CVE-2026-68420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: reject optional IPTFS templates in outbound policies syzbot reported a stack-out-of-bounds read in xfrm_state_find() which flows from xfrm_tmpl_resolve_one(). Commit 3d776e31c841 (\"xfrm: Reject optional tunnel/BEET mode templates in outbound policies\") disallowed optional tunnel and BEET in outbound policies to prevent this. Later when IPTFS added, it was not covered by that fix and can still trigger the out-of-bounds read; Extend the check to disallow optional IPTFS in outbound policies as well. IPTFS should be identical to tunnel mode. IN and FWD policies are not affected: xfrm_tmpl_resolve_one() is only reachable via the outbound path. Reproducer, before: ip link add dummy0 type dummy ip link set dummy0 up ip addr add 10.1.1.1/24 dev dummy0 ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 mode transport ping -W 1 -c 1 10.1.1.2 PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data. [ 64.168420] ================================================================== [ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844 [ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full) [ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 64.169977] Call Trace: [ 64.169977] [ 64.169977] dump_stack_lvl+0x47/0x70 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] print_report+0x152/0x4b0 [ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0 [ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20 [ 64.169977] ? __virt_addr_valid+0x21b/0x230 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] kasan_report+0xa8/0xd0 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm_dst_hash+0x24/0xc0 [ 64.169977] xfrm_state_find+0xa2d/0x2f90 [ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570 [ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10 [ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 64.169977] ? kernel_text_address+0x5b/0x80 [ 64.169977] ? __kernel_text_address+0xe/0x30 [ 64.169977] ? unwind_get_return_address+0x5e/0x90 [ 64.169977] ? arch_stack_walk+0x8c/0xe0 [ 64.169977] xfrm_tmpl_resolve+0x130/0x200 [ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10 [ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110 [ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10 [ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310 [ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80 [ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10 [ 64.169977] ? ip_route_output_key_hash+0xc6/0x110 [ 64.169977] ? kasan_save_track+0x10/0x30 [ 64.169977] xfrm_lookup_route+0x18/0xe0 [ 64.169977] ip4_datagram_release_cb+0x4c9/0x530 [ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10 [ 64.169977] ? do_raw_spin_lock+0x71/0xc0 [ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 64.169977] release_sock+0xb0/0x170 [ 64.169977] udp_connect+0x43/0x50 [ 64.169977] __sys_connect+0xa6/0x100 [ 64.169977] ? alloc_fd+0x2e9/0x300 [ 64.169977] ? __pfx___sys_connect+0x10/0x10 [ 64.169977] ? preempt_latency ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68421", "url": "https://ubuntu.com/security/CVE-2026-68421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx() put_prev_task_scx() warns when a runnable task drops to a lower sched_class without SCX_OPS_ENQ_LAST, on the assumption that balance_one() would have kept it running. Core scheduling breaks that: a forced-idle SMT sibling reschedules through the core_pick fast path in pick_next_task(), which skips pick_task_scx() and thus balance_one(), so a runnable task can drop to idle with ENQ_LAST unset. Gate the warning on sched_cpu_cookie_match(): a cookie mismatch means core scheduling forced the idle, while a match (or core scheduling off) still catches a genuine missing-ENQ_LAST drop.", "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-68426", "url": "https://ubuntu.com/security/CVE-2026-68426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix stale skb->prev after async crypto steals a GSO segment skb_gso_segment() leaves the segment list head with ->prev pointing at the last segment, an invariant validate_xmit_skb_list() relies on when it sets its tail pointer (tail = skb->prev). When validate_xmit_xfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validate_xmit_skb_list() later does tail->next = skb, writing through that stale pointer -- a use-after-free. Repoint skb->prev at the last retained segment before returning.", "cve_priority": "critical", "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-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-2023-20585", "url": "https://ubuntu.com/security/CVE-2023-20585", "cve_description": "Insufficient checks of the RMP on host buffer access in IOMMU may allow an attacker with privileges and a compromised hypervisor to trigger an out of bounds condition without RMP checks, resulting in a potential loss of confidential guest integrity.", "cve_priority": "low", "cve_public_date": "2026-04-16 19:16:00 UTC" }, { "cve": "CVE-2026-68364", "url": "https://ubuntu.com/security/CVE-2026-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix ISM dc_lock deadlock during suspend [Why] System hang observed during suspend/resume while video is playing. amdgpu_dm_ism_disable() is called under dc_lock and waits for ISM delayed work via disable_delayed_work_sync(). The work handlers themselves take dc_lock, producing an ABBA deadlock when a worker is in flight at suspend time. [How] Split the disable path into two phases with opposite locking contracts: 1. amdgpu_dm_ism_disable() -- quiesces workers, must NOT hold dc_lock. 2. amdgpu_dm_ism_force_full_power() (new) -- drives the ISM FSM back to FULL_POWER_RUNNING, must hold dc_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72064", "url": "https://ubuntu.com/security/CVE-2026-72064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Sync page pool RX frags for CPU MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack.", "cve_priority": "medium", "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-72098", "url": "https://ubuntu.com/security/CVE-2026-72098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: fix buffer overflow in FEC calculation There's a buffer overflow in dm-verity-fec: if (neras && *neras <= v->fec->roots) \tfio->erasures[(*neras)++] = i; This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72248", "url": "https://ubuntu.com/security/CVE-2026-72248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: support IPIP tunnel with direct xmit The combination of IPIP tunnel with direct xmit, eg. bridge device, breaks because no dst_entry is provided to check the skb headroom and to set the iph->frag_off field. This leads to invalid dst usage and can trigger a crash in the tunnel transmit path. Fix this by moving dst_cache and dst_cookie out of the runtime union so that they can be shared by neighbour, xfrm, and direct tunnel flows. For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve route state in these shared fields and release it through the common dst release path. Since dst_entry is now available to the three supported xmit modes and dst_release() already deals with NULL dst, remove the xmit type check in nft_flow_dst_release(). Moreover, skip the check if the dst entry is NULL in nf_flow_dst_check() which is now the case for the direct xmit case. Based on patch from Rein Wei .", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72249", "url": "https://ubuntu.com/security/CVE-2026-72249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: use dst in this direction when pushing IPIP header When pushing the IPIP header, the route of the other direction is used to calculate the headroom, use the route in this direction. Accessing the other tuple to set the IP source and destination is fine because this tuple does not provide such information to avoid storing redundant information. However, this tuple already provides the dst for this direction, this went unnoticed because this bug affects headroom and iph->frag_off only at this stage.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72287", "url": "https://ubuntu.com/security/CVE-2026-72287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the \"normal\" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a \"late\" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72329", "url": "https://ubuntu.com/security/CVE-2026-72329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/liquidio: drop cached VF pci_dev LUT The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST. Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72355", "url": "https://ubuntu.com/security/CVE-2026-72355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix barriering when walking subrequest list Fix the barriering used when walking the subrequest list in retry as there's a possibility of seeing a subreq that's just been added by the application thread.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72412", "url": "https://ubuntu.com/security/CVE-2026-72412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/mm: Fix handling of _PAGE_UNUSED pte bit The _PAGE_UNUSED softbit should not really be lying around. Its sole purpose is to signal to try_to_unmap_one() and try_to_migrate_one() that the page can be discarded instead of being moved / swapped. KVM has no way to know why a page is being unmapped, so it sets the bit on userspace ptes corresponding to unused guest pages every time they get unmapped. KVM has no reasonable way to clear the bit once the page is in use again. While set_ptes() checks and clears the bit, other paths that set new ptes did not. This led to used pages being thrown out as if they were unused, causing guest corruption. Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in set_pte(), i.e. whenever a present pte is getting set. The check in set_ptes() is then redundant and can be removed. Also fix gmap_helper_try_set_pte_unused() to only set the bit if the pte is present; the _PAGE_UNUSED bit is only defined for present ptes and thus should not be set for non-present ptes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72417", "url": "https://ubuntu.com/security/CVE-2026-72417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto() Add sanity check for iph->ihl field in nf_flow_ip4_tunnel_proto() before using it to compute the header size, avoiding out-of-bounds access with malformed IP headers. While at it, use iph->protocol instead of the hardcoded IPPROTO_IPIP constant when setting ctx->tun.proto and reference ctx->tun.hdr_size when updating ctx->offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72442", "url": "https://ubuntu.com/security/CVE-2026-72442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: fix and simplify IP6IP6 tunnel handling Fix nf_flow_ip6_tunnel_proto() to use pskb_may_pull() instead of skb_header_pointer() to ensure the outer IPv6 header is in the skb headroom, which is required for subsequent packet processing. Move ctx->offset update inside the IPPROTO_IPV6 conditional block since it should only be adjusted when an IP6IP6 tunnel is actually detected. Simplify the rx path by removing ipv6_skip_exthdr() and checking ip6h->nexthdr directly, as the flowtable fast path only handles simple IP6IP6 encapsulation without extension headers. Drop the tunnel encapsulation limit destination option support from the tx path to match, since the rx path no longer handles extension headers. Remove the encap_limit parameter from nf_flow_offload_ipv6_forward(), nf_flow_tunnel_ip6ip6_push() and nf_flow_tunnel_v6_push(), along with the ipv6_tel_txoption struct and related headroom/MTU adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72463", "url": "https://ubuntu.com/security/CVE-2026-72463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix dev use-after-free in xfrm async resumption xfrm async resumption hold skb->dev refcnt until after transport_finish. However, xfrm_rcv_cb may modify skb->dev to tunnel dev without taking device reference, such as vti_rcv_cb. The subsequent async resumption will decrement the tunnel device's reference count, which lead to uaf of tunnel dev and refcnt leak of orig dev as below: unregister_netdevice: waiting for vti1 to become free. Usage count = -2 Stash the original skb->dev to fix refcnt imbalance. The new skb->dev set by xfrm_rcv_cb can race with device teardown. Extend rcu protection over xfrm_rcv_cb and transport_finish to prevent races.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72477", "url": "https://ubuntu.com/security/CVE-2026-72477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: call _ntfs_bad_inode() when failing to rename It is safe to call _ntfs_bad_inode on live inodes since: commit 519b078998ce (\"fs/ntfs3: Exclude call make_bad_inode for live nodes.\") The WARN_ON was added when it wasn't safe by: commit d99208b91933 (\"fs/ntfs3: cancle set bad inode after removing name fails\") Replace the WARN_ON with a call to _ntfs_bad_inode() to prevent further operations on the inconsistent inode.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72493", "url": "https://ubuntu.com/security/CVE-2026-72493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: serialize netif_running() check in enqueue_to_backlog() Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup(). The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit). Commit e9e4dd3267d0 (\"net: do not process device backlog during unregistration\") introduced a lockless netif_running() check in enqueue_to_backlog() to prevent queuing packets to an unregistering device. However, this creates a TOCTOU race window. A lockless transmitter (like veth_xmit) can pass the check before dev_close() clears IFF_UP. If the transmitter is then delayed, flush_all_backlogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed. Fix this by moving the netif_running() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netif_running() after the flush/close completes (so it gets dropped).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72494", "url": "https://ubuntu.com/security/CVE-2026-72494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Replace waitqueue and flag with completion The driver previously used a waitqueue along with an explicit request_done flag, but without proper barriers around request_done. An earlier patch by Gui-Dong Han attempted to fix this by adding the missing memory barriers. Rather than adding the barriers, this patch replaces the waitqueue+flag with a completion, which is designed for this exact purpose.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72496", "url": "https://ubuntu.com/security/CVE-2026-72496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Proper rollback if the ioremap fails bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74269", "url": "https://ubuntu.com/security/CVE-2026-74269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt: fix head underflow on XDP head-grow The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free. The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with this commit applied causes the test to run successfully to completion. The other rx_skb_func implementations don't have this issue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74350", "url": "https://ubuntu.com/security/CVE-2026-74350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate fast symlink target during inode read ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment. A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer. Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated. This keeps malformed fast symlinks from reaching the read path. Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x19f/0x330 (?:?) kasan_report+0xe0/0x110 (?:?) kasan_check_range+0x105/0x1b0 (?:?) __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72495", "url": "https://ubuntu.com/security/CVE-2026-72495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid repeated requests to allocate WC pages Applications can request multiple WC pages for the same ucontext. As of now, only 1 WC page per ucontext is supported. Add a lock to avoid concurrent access and a check to fail repeated requests. Also, if the mmap entry insert fails for the WC, free the Doorbell page index mapped for the WC page.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72501", "url": "https://ubuntu.com/security/CVE-2026-72501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Initialize dpi variable to zero dpi is initialized only for BNXT_RE_ALLOC_WC_PAGE, but copied for all the cases. So initialize the dpi to 0.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72278", "url": "https://ubuntu.com/security/CVE-2026-72278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Re-translate VNCR before injecting abort KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor updates and MMU faults.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68083", "url": "https://ubuntu.com/security/CVE-2026-68083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix path resolution in ksmbd_vfs_kern_path_create The SMB2 open lookup is rooted at the share with LOOKUP_BENEATH, but the create/mkdir/hardlink sink is not: ksmbd_vfs_kern_path_create() builds an absolute path with convert_to_unix_name() and resolves it from AT_FDCWD via start_creating_path(), so a \"..\" component is walked from the real filesystem root and escapes the export. An authenticated client races a missing path component so the rooted open lookup returns -ENOENT (taking the create branch) while the same component is present (a directory) when the create walk runs; the create then resolves \"..\" out of the share. Root the create walk at the share like the lookup and rename paths already are: resolve the parent with vfs_path_parent_lookup(..., LOOKUP_BENEATH, &share_conf->vfs_path) and create the final component with start_creating_noperm(). convert_to_unix_name() then has no callers and is removed.", "cve_priority": "high", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-68457", "url": "https://ubuntu.com/security/CVE-2026-68457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use opener credentials for FSCTL mutations SET_SPARSE, SET_ZERO_DATA and SET_COMPRESSION operate on an open SMB handle but call VFS xattr, fallocate or fileattr helpers with the current ksmbd worker credentials. Those helpers can revalidate inode permissions, ownership and LSM policy independently of the SMB handle access mask. Run each operation with the credentials captured in the target file when the handle was opened. Keep credential handling local to these single-file FSCTLs rather than applying session credentials to the complete IOCTL handler, which also contains handle-less and multi-handle operations.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72041", "url": "https://ubuntu.com/security/CVE-2026-72041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: use sk_msg_free_partial to fix partial send sk_msg_free_partial() ensures consistency of the skmsg at every iteration, without having to manually handle uncharges and offsets. This simplifies the code, and fixes some bugs in skmsg accounting when we don't send the full contents.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72046", "url": "https://ubuntu.com/security/CVE-2026-72046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing.", "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-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21: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-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72137", "url": "https://ubuntu.com/security/CVE-2026-72137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: nat_keepalive: avoid double free on send error nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6 send helper reports an error. That cleanup is only correct before the skb is handed to the output path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the networking stack may already have consumed the skb before returning an error, so freeing it again is unsafe. Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4() and nat_keepalive_send_ipv6(), where the caller still owns the skb, and keep nat_keepalive_send() responsible only for family dispatch and the unsupported-family cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72139", "url": "https://ubuntu.com/security/CVE-2026-72139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: defer md5sig_info kfree past RCU grace period in tcp_connect The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: \tif (needs_md5) { \t\ttcp_ao_destroy_sock(sk, false); \t} else if (needs_ao) { \t\ttcp_clear_md5_list(sk); \t\tkfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); \t} Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with tcp-diag]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72191", "url": "https://ubuntu.com/security/CVE-2026-72191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: validate split-point offset in indx_insert_into_buffer indx_insert_into_buffer() computes used = used1 - to_copy - sp_size; memmove(de_t, Add2Ptr(sp, sp_size), used - le32_to_cpu(hdr1->de_off)); where sp and sp_size come from hdr_find_split(). hdr_find_split() walks entries by le16_to_cpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFS_DE). index_hdr_check(), the on-load gatekeeper, only validates header-level fields (used, total, de_off) and does not walk per-entry sizes. A crafted NTFS image whose leaf INDEX_HDR reports used == total but contains one interior NTFS_DE with size = 0xFFF0 therefore passes validation, descends to indx_insert_into_buffer() through the ntfs_create() -> indx_insert_entry() path, and makes hdr_find_split() return an sp whose sp_size (0xFFF0) greatly exceeds the remaining bytes in the buffer. The u32 subtraction underflows and the memmove count becomes a near-4-GiB value, producing an out-of-bounds kernel write that corrupts adjacent allocations and panics the kernel. Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a single 'touch' inside the mounted directory; crash site resolves to fs/ntfs3/index.c at the memmove. Trigger requires only local mount of an attacker-supplied filesystem image (USB, loopback, or removable media auto-mount). Reject the split whenever the chosen sp plus its declared size already extends past hdr1->used. This is the minimal fix; it preserves the existing hdr_find_split() contract and relies on the same out: cleanup path as the pre-existing error returns. A prior OOB read in the very same indx_insert_into_buffer() memmove was fixed in commit b8c44949044e (\"fs/ntfs3: Fix OOB read in indx_insert_into_buffer\") by tightening hdr_find_e(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdr_find_split(), not hdr_find_e(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72217", "url": "https://ubuntu.com/security/CVE-2026-72217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing xdr_buf_to_bvec() writes a bio_vec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it. rq_bvec, the array passed by nfsd_vfs_write(), is allocated to exactly rq_maxpages entries with no slack. The OOB store can land in adjacent slab memory; the bv_len and bv_offset fields written there are derived from client-supplied RPC payload sizes. Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72220", "url": "https://ubuntu.com/security/CVE-2026-72220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp->rq_procinfo->pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72221", "url": "https://ubuntu.com/security/CVE-2026-72221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: wait for in-flight TLS handshake callback when cancel loses race When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed. The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result. If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue. If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed. Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed to fire because handshake_complete() invokes svc_tcp_handshake_done() unconditionally once it has set HANDSHAKE_F_REQ_COMPLETED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72222", "url": "https://ubuntu.com/security/CVE-2026-72222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: pin svc_xprt across the asynchronous TLS handshake callback svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of(). Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done. The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry. Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all(). [cel: rewrote commit message to describe the actual change]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72277", "url": "https://ubuntu.com/security/CVE-2026-72277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the simpler thing for now and just reject everything that isn't memory.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72279", "url": "https://ubuntu.com/security/CVE-2026-72279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR KVM currently maps the L1 VNCR into the host stage-1 by relying entirely on the permissions of the guest stage-1. At the same time, it is entirely possible that the backing PFN is read-only (e.g. RO memslot), meaning that the L1 VNCR should use at most a read-only mapping. Cache the writability of the PFN in the VNCR TLB and use it to constrain the resulting fixmap permissions. Promote VNCR permission faults to an SEA in the case where the guest attempts to write to a read-only endpoint. Conveniently, this also plugs a page leak found by Sashiko [*] resulting from the early return for a read-only PFN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72288", "url": "https://ubuntu.com/security/CVE-2026-72288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling Hyunwoo Kim reports some really bad races should the following situation occur: - LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C If the last two race nicely enough, vgic_prune_ap_list() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows. The fix is two-fold: - Before dropping the irq and ap_list locks, take a reference on the irq - Do not try to handle migration of the pending bit: there is no expectation that this state is retained, as per the architecture With that, we're sure that the interrupt is still around, and we safely remove it from the AP list as it has no target at this stage (unless another interrupt fires, but that's another story).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "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-72317", "url": "https://ubuntu.com/security/CVE-2026-72317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: pin upper rpc_clnt across the TLS connect_worker The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt. The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported. Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one. The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72318", "url": "https://ubuntu.com/security/CVE-2026-72318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate DFS referral string offsets parse_dfs_referrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server. Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative max_len is then passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds. Validate each string offset before deriving the string pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72320", "url": "https://ubuntu.com/security/CVE-2026-72320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_lookup: fix catchall element handling with inverted lookups nft_lookup_eval() decides whether a lookup matched (`found`) from the direct set lookup and priv->invert before falling back to the catchall element used by interval sets (e.g. nft_set_rbtree) for the open-ended default range. Since `found` is never recomputed after `ext` is replaced by the catchall lookup, inverted lookups (NFT_LOOKUP_F_INV, \"!= @set\") can wrongly match or wrongly skip the catchall element, producing the wrong verdict. Fold the catchall lookup into `ext` before computing `found`, matching the order already used by nft_objref_map_eval().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72366", "url": "https://ubuntu.com/security/CVE-2026-72366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_create_write_req() to handle async cache object creation netfs_create_write_req() will skip caching if the fscache cookie is disabled, but this is a problem because async cache object creation might not have got far enough yet that has been enabled - thereby causing the call to fscache_begin_write_operation() to be skipped. Fix this by removing the checks on the cookie and delegating this to fscache_begin_write_operation().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72381", "url": "https://ubuntu.com/security/CVE-2026-72381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of fp->owner.name in durable handle owner check Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d (\"ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd\") made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized. BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8 Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72393", "url": "https://ubuntu.com/security/CVE-2026-72393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: don't cache shinfo across skb realloc fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb including the shared info. We can't use the pointer calculated before the call. BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0 Read of size 4 at addr ff110000262edd98 by task swapper/5/0 Call Trace: fbnic_tx_lso.isra.0+0x668/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 Allocated by task 8653: __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xcc/0x6c0 sock_alloc_send_pskb+0x327/0x3f0 __ip_append_data+0x188b/0x47a0 ip_make_skb+0x24a/0x300 udp_sendmsg+0x14d2/0x21e0 Freed by task 0: kfree+0x123/0x5a0 pskb_expand_head+0x36c/0xfa0 fbnic_tx_lso.isra.0+0x500/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 sch_direct_xmit+0x25b/0x1100 The buggy address belongs to the object at ff110000262edc40 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 344 bytes inside of freed 640-byte region [ff110000262edc40, ff110000262ede", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72398", "url": "https://ubuntu.com/security/CVE-2026-72398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: add INIT verification after cookie unpacking In SCTP handshake, the INIT chunk is initially processed by the server and embedded into the cookie carried in INIT-ACK. The client then returns this cookie via COOKIE-ECHO, where the server unpacks it and reconstructs the original INIT chunk. When cookie authentication is enabled, the cookie contents are protected against tampering, so reusing the unpacked INIT without re-verification is safe. However, when cookie authentication is disabled, the reconstructed INIT can no longer be trusted. In this case, the INIT must be explicitly validated after unpacking to avoid processing potentially tampered data. Add sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO processing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook()) when cookie_auth_enable is disabled. On failure, the new association is freed and the packet is discarded. Also tighten cookie validation in sctp_unpack_cookie() by verifying the embedded chunk type is SCTP_CID_INIT before treating it as an INIT chunk. Finally, update sctp_verify_init() to validate parameter bounds using the actual embedded INIT length instead of chunk->chunk_end, since the INIT stored in COOKIE-ECHO may not span the entire chunk buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72399", "url": "https://ubuntu.com/security/CVE-2026-72399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: check the number of BDs needed for xdp_frame The size of xdp_redirect_arr array is ENETC_MAX_SKB_FRAGS. However, the number of fragments contained in xdp_frame may be greater than or equal to ENETC_MAX_SKB_FRAGS, which will cause the access to xdp_redirect_arr to be out of bounds.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72429", "url": "https://ubuntu.com/security/CVE-2026-72429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix type confusion of dst_entry IOAM uses a dummy dst_entry(null_dst) to mark that the destination should not be changed after the transformation. This dst is stored in the IOAM lwt state and may be passed to dst_cache_set_ip6(). However, the IPv6 dst cache path eventually calls rt6_get_cookie(), which treats the dst_entry as part of a struct rt6_info. Since the null_dst was embedded directly as a struct dst_entry in struct ioam6_lwt, this resulted in an invalid cast and rt6_get_cookie() reading fields from the wrong object. In practice, the wrong cookie is not used while dst->obsolete is zero, but rt6_get_cookie() may also access per-cpu value when rt->sernum is zero. In this case, rt->sernum aliases ioam6_lwt::cache::reset_ts, which can become zero, making this a potential invalid pointer access. Fix this by embedding a full struct rt6_info for the dummy IPv6 route and passing its dst member to the dst APIs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72436", "url": "https://ubuntu.com/security/CVE-2026-72436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash types Sashiko pointed out that there are a few lockless RCU readers using test_bit() which is a relaxed atomic operation and provides no memory barrier guarantees. Use test_bit_acquire() instead where the operation may run parallel with add/del/gc, i.e. is not one from the next cases - protected by region lock - in a set destroy phase - in a new/temporary set creation phase", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72451", "url": "https://ubuntu.com/security/CVE-2026-72451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix xfrm state cache insertion race The xfrm input state cache insertion code checks the validity of the state before acquiring the global xfrm_state_lock. Thus it's possible for someone else to kill the state after it passed the validity check, and then the insertion will add the dead state to the cache. Fix this by moving the validity check inside the lock. This entire function is called on the input path, where BH must be off (e.g., the caller of this function xfrm_input acquires its spinlocks without disabling BH). So there is no need to disable BH here or take the RCU read lock. Remove both and replace them with an assertion that trips if BH is accidentally enabled on some future calling path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72472", "url": "https://ubuntu.com/security/CVE-2026-72472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: use nfsi->rwsem to protect traversal of the file lock list Lingfeng identified a bug and suggested two solutions, but both appear to have issues. Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case. Furthermore, after commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk. Regarding the bug fixed by commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), it has been resolved after commit 0460253913e5 (\"NFSv4: nfs4_do_open() is incorrectly triggering state recovery\") because all slots are drained before calling nfs4_do_reclaim, which prevents concurrent stateid changes along this path. Also, nfs_delegation_claim_locks does not cause this concurrency either since when _nfs4_proc_setlk is called with NFS_DELEGATED_STATE, no RPC is sent, so nfs4_lock_done is not called. Therefore, nfs4_lock_delegation_recall from nfs_delegation_claim_locks is the first time the stateid is set.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72473", "url": "https://ubuntu.com/security/CVE-2026-72473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decouple req recycling from RPC completion rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer. Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off. The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry. Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied. Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected. Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released. The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74310", "url": "https://ubuntu.com/security/CVE-2026-74310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/net: complete zerocopy ubufs only once vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74345", "url": "https://ubuntu.com/security/CVE-2026-74345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix endpoint/socket association handling Disassociating a socket from an endpoint via siw_socket_disassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within. This fixes a: BUG: KASAN: slab-use-after-free in siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1053 drivers/infiniband/sw/siw/siw_cm.c:1075) which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74361", "url": "https://ubuntu.com/security/CVE-2026-74361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: fix FDP fdpcidx bounds check The fdpcidx bounds check sets n = NUMFDPC + 1 but used > instead of >=, incorrectly accepting fdp_idx when it equals n (i.e. NUMFDPC + 1).", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74401", "url": "https://ubuntu.com/security/CVE-2026-74401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix add msg handle in send_queue ordered In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as \"before(mh->seq, seq)\" will stop to check for older sequence numbers that are ordered in the tail of \"node->send_queue\". The side effects of not having it correct ordered regarding \"before(mh->seq, seq)\" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74406", "url": "https://ubuntu.com/security/CVE-2026-74406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74428", "url": "https://ubuntu.com/security/CVE-2026-74428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix double unlock in rxrpc_recvmsg() Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74433", "url": "https://ubuntu.com/security/CVE-2026-74433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix UAF in rxgk_issue_challenge() Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74434", "url": "https://ubuntu.com/security/CVE-2026-74434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Don't move a peeked OOB message onto the pending queue rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so only unlink it from recvmsg_oobq and then move it onto pending_oobq or free it when the message is actually consumed.", "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-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-74439", "url": "https://ubuntu.com/security/CVE-2026-74439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clear Present bit before tearing down scalable-mode context entry device_pasid_table_teardown() zeroes the 128-bit scalable-mode context entry with context_clear_entry() while the Present bit is still set. This creates a window where the hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behavior or spurious faults. The context-cache invalidation is issued only after the entry has been zeroed, and intel_pasid_free_table() then frees the PASID directory pages, so the IOMMU can keep walking a stale Present=1 entry that points at freed memory. While x86 provides strong write ordering, the compiler may reorder the two 64-bit writes to the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Commit c1e4f1dccbe9d (\"iommu/vt-d: Clear Present bit before tearing down context entry\") fixed this exact pattern in domain_context_clear_one() and the copied-context path, but device_pasid_table_teardown() was not converted. Align it with the \"Guidance to Software for Invalidations\" in the VT-d spec, Section 6.5.3.3, using the same ownership handshake as the sibling fix: clear only the Present bit, flush it to the IOMMU, perform the context-cache invalidation, and only then zero the rest of the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2165483, 2165484, 2165407, 2166547, 2166443, 2166356, 2165872, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165407, 2165040, 2161748, 2163508, 2163214, 2162904, 2162045, 2164967, 2160082, 2164504, 2156316, 2164716, 2164516, 2163375, 2162803, 2163062, 2132119, 2163293, 2160200, 2158858, 2162704, 2162695, 2164666, 2164666, 2163121 ], "changes": [ { "cves": [ { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-68105", "url": "https://ubuntu.com/security/CVE-2026-68105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix kernel panic during driver load failure Avoid kernel panic if MES init fails during driver load. The KIQ ring is falsely marked as ready as ASICs that use MES, KIQ is owned by MES. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu] Call Trace: gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu] amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu] amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu] amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu] amdgpu_gart_unbind+0x72/0x90 [amdgpu] amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu] amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu] amdttm_tt_unpopulate+0x29/0x70 [amdttm] ttm_bo_put+0x1eb/0x360 [amdttm] amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu] amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu] amdgpu_irq_fini_hw+0x58/0x80 [amdgpu] amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu] amdgpu_driver_load_kms+0x60/0xa0 [amdgpu] amdgpu_pci_probe+0x28e/0x6d0 [amdgpu] pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280 __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53 (cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68109", "url": "https://ubuntu.com/security/CVE-2026-68109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68114", "url": "https://ubuntu.com/security/CVE-2026-68114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit e4d99e04b2e9b13b97d3b17804c735f62689db23)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68431", "url": "https://ubuntu.com/security/CVE-2026-68431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate minimum PDU size for transform requests The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68138", "url": "https://ubuntu.com/security/CVE-2026-68138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: serialize qdisc_rtab_list against concurrent get/put qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68082", "url": "https://ubuntu.com/security/CVE-2026-68082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix two unsafe bare decodes in decode_lockers() decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-08 10:16:00 UTC" }, { "cve": "CVE-2026-68159", "url": "https://ubuntu.com/security/CVE-2026-68159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68163", "url": "https://ubuntu.com/security/CVE-2026-68163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_vma_mapped: fix device-private PMD handling Commit 65edfda6f3f2 (\"mm/rmap: extend rmap and migration support device-private entries\") introduced the concept of device-private PMD entries, but did not correctly update the rmap walk code to account for them. As a result, when page_vma_mapped_walk() encounters device-private PMD entries, it takes no action other than to acquire the PMD lock and exit. However this is highly problematic for two reasons - firstly, device private entries possess a PFN so check_pmd() needs to be called to ensure an overlapping PFN range. Secondly, and more importantly, if PVMW_MIGRATION is set the caller assumes the returned entry is a migration entry, resulting in memory corruption when the caller tries to interpret the device private entry as such. In addition, commit 146287290023 (\"mm/huge_memory: implement device-private THP splitting\") allowed device private PMDs to be split like THP mappings, but again did not update this code path. As a result, we might race a PMD split prior to acquiring the PMD lock. This patch addresses all of these issues by invoking check_pmd(), ensuring PMVW_MIGRATION is not set and checks whether a split raced us we do for PMD THP and migration entries. Instead of checking for a subset of the cases after taking the pmd_lock(), put device-private along with pmd_trans_huge() and pmd_is_migration_entry(). Also remove thp_migration_supported() as it is already guarded by pmd_is_migration_entry(). [akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68166", "url": "https://ubuntu.com/security/CVE-2026-68166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: prevent registration of special VMAs Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68170", "url": "https://ubuntu.com/security/CVE-2026-68170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix stale skb->sk reference on subflow close The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68177", "url": "https://ubuntu.com/security/CVE-2026-68177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Delay module ref count for \"enable_event\" trigger Triggers are now delayed from freeing, but can still be triggered until after the RCU grace period has ended. The freeing of the enable_event data is put into the private_data_free() callback, but the put of the module refcount is done immediately. It is possible that if a module is removed that has an event that would enable (or disable) it is still active, it can read the data of the module after it is removed causing a use-after-free bug. Move the trace_event_put_ref() that releases the module into the delayed callback so that the module can not be removed until any reference to its events are finished.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68191", "url": "https://ubuntu.com/security/CVE-2026-68191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix NULL pointer dereference in rhash table destroy When unbinding the ath12k driver, kernel NULL pointer dereferences occur in irq_work_sync() called from rhashtable_destroy(). Two hash tables are affected: 1. ath12k_link_sta hash table in ath12k_base 2. ath12k_dp_link_peer hash table in ath12k_dp The issue happens because the destroy functions are called unconditionally in cleanup paths, but the hash tables are only initialized late in their respective init functions. If the device was never fully started or if the init functions failed before initializing the hash tables, the pointers will be NULL. The issues are always reproducible from a VM because the MSI addressing initialization is failing. Call trace for ath12k_link_sta_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_link_sta_rhash_tbl_destroy+0x19/0x40 [ath12k] ath12k_core_stop+0xe/0x80 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Call trace for ath12k_dp_link_peer_rhash_tbl_destroy: RIP: irq_work_sync+0x1e/0x70 rhashtable_destroy+0x12/0x60 ath12k_dp_link_peer_rhash_tbl_destroy+0x29/0x50 [ath12k] ath12k_dp_cmn_device_deinit+0x21/0x140 [ath12k] ath12k_core_hw_group_cleanup+0x6b/0xb0 [ath12k] ath12k_pci_remove+0x60/0x110 [ath12k] Fix this by adding NULL checks before calling rhashtable_destroy() in both destroy functions. The NULL check approach was chosen because the rhashtable pointer serves as the initialization state indicator. The init can fail at various points, leaving some components uninitialized. Checking the pointer directly is simpler than adding separate state flags that would need synchronization.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64586", "url": "https://ubuntu.com/security/CVE-2026-64586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: drain bus_reset work on device removal brcmf_fw_crashed() and the debugfs \"reset\" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs \"reset\" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. 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-68208", "url": "https://ubuntu.com/security/CVE-2026-68208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: Fix the error code of devm_kzalloc() in vip_probe_slice() In vip_probe_slice(), the error check for devm_kzalloc() incorrectly uses PTR_ERR_OR_ZERO() which returns 0 for NULL pointer. Return -ENOMEM for devm_kzalloc() failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68224", "url": "https://ubuntu.com/security/CVE-2026-68224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mali-c55: Fix possible ERR_PTR in enable_streams The media_pad_remote_pad_unique() function returns either a valid pointer or an ERR_PTR() on failure (-ENOTUNIQ if multiple links are enabled, -ENOLINK if no connected pad is found). The return value was assigned directly to isp->remote_src and dereferenced in the next line without checking for errors, which could lead to an ERR_PTR dereference. Add proper error checking with IS_ERR() before dereferencing the pointer. Also set isp->remote_src to NULL on error to maintain consistency with other error paths in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68237", "url": "https://ubuntu.com/security/CVE-2026-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: fix indefinite fence wait during GPU reset pre_reset only force-completes fences of MAPPED queues. A queue in any other state (e.g. mid-eviction) keeps its last_fence pending; after a GPU reset that fence never signals, so the eviction/suspend worker and process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and wedge the machine: INFO: task kworker/6:28 blocked for more than 120 seconds. Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu] Call Trace: dma_fence_wait_timeout+0x7e/0x130 amdgpu_userq_evict+0x67/0x140 [amdgpu] amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu] process_scheduled_works+0xa6/0x420 Force-complete every queue's fence regardless of state. The unmap and mark-hung step stays gated on MAPPED, since unmapping a queue that is not mapped is invalid. (cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68240", "url": "https://ubuntu.com/security/CVE-2026-68240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: publish dpagemap early to avoid device mapping leak on error drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68242", "url": "https://ubuntu.com/security/CVE-2026-68242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix NULL deref on sched_engine alloc failure Avoid using intel_context_put() before intel_context_init() in execlists_create_virtual() as the kref_put() inside would lead to NULL deref on the IOCTL path when sched_engine allocation fails. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68254", "url": "https://ubuntu.com/security/CVE-2026-68254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: require valid min/max vfreq for VRR Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68436", "url": "https://ubuntu.com/security/CVE-2026-68436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use kvzalloc to allocate struct dc struct dc has grown large over time (most of it the two inlined dc_scratch_space copies) and now sits close to the page allocator's 4 MiB contiguous allocation limit. Its actual size is not fixed by the source alone, it also depends on the compiler and the .config, so it can easily cross 4 MiB, e.g. with a newer GCC or a config change. dc_create() allocates it with kzalloc(). Once struct dc exceeds 4 MiB the request is rounded up to order 11 (8 MiB), which is above MAX_PAGE_ORDER, so the page allocator warns and returns NULL. dc_create() then fails, DM init fails and amdgpu probe aborts with -EINVAL: WARNING: mm/page_alloc.c:5197 at __alloc_frozen_pages_noprof+0x2f9/0x380 dc_create+0x38/0x660 [amdgpu] amdgpu_dm_init+0x2d9/0x510 [amdgpu] dm_hw_init+0x1b/0x90 [amdgpu] amdgpu_device_init.cold+0x150d/0x1e13 [amdgpu] amdgpu_driver_load_kms+0x19/0x80 [amdgpu] amdgpu_pci_probe+0x1e2/0x4c0 [amdgpu] dc_create() then returns NULL and DM init fails, which aborts the whole GPU init and makes amdgpu probe fail with -EINVAL (\"hw_init of IP block failed -22\"), leaving the display unusable. The subsequent amdgpu_irq_put() warnings during teardown are just fallout of unwinding a half-initialized device. struct dc is a software-only bookkeeping structure that is never handed to hardware DMA and is only ever kept as an opaque pointer, so it does not require physically contiguous memory. Allocate it with kvzalloc() (and free it with kvfree()) so that the allocator can fall back to vmalloc() when a contiguous allocation of that size is not available, which also avoids the MAX_PAGE_ORDER warning entirely. v2: - Rebase to amd-staging-drm-next. (cherry picked from commit 991e0516a8072f2292681c6ae98a924ab0e32575)", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68447", "url": "https://ubuntu.com/security/CVE-2026-68447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size from hardware without bounding it to the allocated BO region. If the HW field is larger than the queue's control stack allocation, memcpy reads past the BO into adjacent GTT memory and can leak kernel data to userspace. Store the page-aligned control stack BO size in mqd_manager and clamp checkpoint copies and reported checkpoint sizes to min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound for multi-XCC v9.4.3 checkpoint layout. (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3)", "cve_priority": "high", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68264", "url": "https://ubuntu.com/security/CVE-2026-68264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: Reset current_op in xe_pt_update_ops_init() xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it. After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind. Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry. Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(). v2 (Matt): - Add details in commit message. - Add Fixes tag and Cc to stable@vger.kernel.org (cherry picked from commit 046045543e530605c441063535e7dca0075369a6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68265", "url": "https://ubuntu.com/security/CVE-2026-68265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO's tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference (cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68267", "url": "https://ubuntu.com/security/CVE-2026-68267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists Unconditionally whitelisting OA registers is a security violation. Set RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers don't get whitelisted by default after probe, gt reset, resume and engine reset. (cherry picked from commit 90511bdcfda97211c01f1d945d4ea616578d8fca)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68273", "url": "https://ubuntu.com/security/CVE-2026-68273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68274", "url": "https://ubuntu.com/security/CVE-2026-68274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix buffer overflow in steered register list allocation The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt->fuse_topo.g_dss_mask, ...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68283", "url": "https://ubuntu.com/security/CVE-2026-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free freeing trigger private data Commit 61d445af0a7c (\"tracing: Add bulk garbage collection of freeing event_trigger_data\") moved the kfree() of event_trigger_data to a kthread that runs tracepoint_synchronize_unregister() before freeing. That removed the synchronization the trigger .free callbacks used to get implicitly and inline from trigger_data_free(). event_hist_trigger_free(), event_hist_trigger_named_free() and event_enable_trigger_free() free their satellite data (hist_data, cmd_ops, enable_data) right after trigger_data_free() returns. With the synchronization now deferred to the kthread, a concurrent tracepoint handler can still reach that data through the list_del_rcu()'d trigger, causing a use-after-free. The histogram teardown must stay synchronous: remove_hist_vars() and unregister_field_var_hists() have to detach a synthetic event from the histogram before the trigger-removal write returns, otherwise a following command races in and the synthetic-event removal fails with -EBUSY, as the trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait with the correct barrier - tracepoint_synchronize_unregister(), matching the free kthread - before freeing. The enable trigger has no such synchronous requirement, and a blocking synchronize there would re-serialize the path that commit deliberately deferred. Give it an optional private_data_free() callback that the free kthread runs after its grace period, and free enable_data from there.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68286", "url": "https://ubuntu.com/security/CVE-2026-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68287", "url": "https://ubuntu.com/security/CVE-2026-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix size calculations for 64-bit attributes net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68288", "url": "https://ubuntu.com/security/CVE-2026-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68289", "url": "https://ubuntu.com/security/CVE-2026-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68291", "url": "https://ubuntu.com/security/CVE-2026-68291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix max_vport related crash on allocation error during init Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000 [ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000 [ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20 [ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000 [ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0 [ 320.417385] PKRU: 55555554 [ 320.417398] Call Trace: [ 320.417412] [ 320.417429] pci_device_remove+0x42/0xb0 [ 320.417459] device_release_driver_internal+0x1a9/0x210 [ 320.417492] driver_detach+0x4b/0x90 [ 320.417516] bus_remove_driver+0x70/0x100 [ 320.417539] pci_unregister_driver+0x2e/0xb0 [ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0 [ 320.417592] ? kmem_cache_free+0x31e/0x550 [ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190 [ 320.417644] ? do_syscall_64+0x38/0x6b0 [ 320.417665] do_syscall_64+0xc8/0x6b0 [ 320.417683] ? clear_bhb_loop+0x30/0x80 [ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 320.417727] RIP: 0033:0x7f963bb30beb", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68303", "url": "https://ubuntu.com/security/CVE-2026-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hvs/v3d: Fix null dereference in unbind The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68312", "url": "https://ubuntu.com/security/CVE-2026-68312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and cifs_close_deferred_file_under_dentry(), when a pending deferred close is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to add the file to the local processing list may fail under memory pressure. The loop breaks immediately, but the cancelled work is no longer pending (it would have called _cifsFileInfo_put()), and the cfile is never added to file_head for processing. The cifsFileInfo reference and the open server handle both leak. Fix by saving the cfile that failed allocation in a local variable, breaking as before, and calling _cifsFileInfo_put() on it after releasing the lock. Any files later in the iteration are unaffected since their deferred work is still pending and will fire normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68316", "url": "https://ubuntu.com/security/CVE-2026-68316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Fix element size accounting for cmd stream validation There are 2 issues with the element size handling in the command stream validation which result in too small of a size calculated when the element size is 16/32/64 bits. For NHWC format, the element size is simply missing from the calculation. The bitfield for the element size is different between IFM/IFM2 and OFM. IFM and IFM2 encode the precision in parameter bits 2:3, while OFM uses bits 1:2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68440", "url": "https://ubuntu.com/security/CVE-2026-68440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix heap overflow when reading module EEPROM txgbe_read_eeprom_hostif() always copies round_up(length, 4) bytes into the caller buffer, which ethtool allocates with exactly 'length' bytes. A non-4-aligned length therefore causes an out-of-bounds write. Copy only the remaining bytes on the final dword instead.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68323", "url": "https://ubuntu.com/security/CVE-2026-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: serialize udp bearer replicast list updates tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev->next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice. cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68441", "url": "https://ubuntu.com/security/CVE-2026-68441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected. This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d (\"bpf: add bpf_redirect() helper\"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available. commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs. Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a wrapper around tcf_classify() for use by qdisc classify functions and tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT, the wrapper converts it to TC_ACT_SHOT, dropping the packet rather than letting it continue silently. Dropping is preferred over letting the packet through because the user immediately sees packet loss. Silently passing the packet through would hide the problem and leave the user wondering why their redirect is not working. The clsact fast path, tc_run() continues to call tcf_classify() directly and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by sch_handle_egress/ingress() calling skb_do_redirect() as before.", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68337", "url": "https://ubuntu.com/security/CVE-2026-68337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject redirect helpers without a bpf_net_context The bpf_redirect*() helpers and skb_do_redirect() obtain the per-task bpf_redirect_info via bpf_net_ctx_get_ri(), which dereferences the current->bpf_net_context unconditionally. That context is established on the paths that run tc BPF such as sch_handle_{ingress,egress}(), *except* for the case where {cls,act}_bpf was attached to a proper qdisc. A program running from there reaches the NULL deref in two ways: * It calls bpf_redirect() directly, which dereferences the context at the top of the helper: tc qdisc add dev eth0 root handle 1: red limit 1MB min 10KB max 20KB \\ avpkt 1000 burst 100 qevent early_drop block 10 tc filter add block 10 pref 1 bpf obj redirect.o * It simply returns TC_ACT_REDIRECT without helper call: tcf_qevent_handle() then dispatches to skb_do_redirect(), which dereferences the context Rather than extending bpf_net_context management into the qdisc path, make the redirect helpers refuse to operate when no context exists, and have tcf_qevent_handle() drop a TC_ACT_REDIRECT verdict instead of calling skb_do_redirect(). Previous behaviour was a crash, so nothing regresses by not supporting it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68345", "url": "https://ubuntu.com/security/CVE-2026-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm_mpam: guard MBWU state before adding it to garbage __destroy_component_cfg() adds each RIS mbwu_state object to the MPAM garbage list when destroying component configuration. However, mbwu_state is allocated per RIS and only for RISes with MBWU monitors. A component can therefore have comp->cfg allocated while some RISes still have ris->mbwu_state set to NULL. Passing a NULL mbwu_state to add_to_garbage() dereferences the NULL pointer inside the macro. Skip RISes that do not have an mbwu_state object before adding them to the garbage list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68347", "url": "https://ubuntu.com/security/CVE-2026-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68375", "url": "https://ubuntu.com/security/CVE-2026-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle partially initialized auxiliary devices bnxt_aux_devices_init() calls auxiliary_device_init() before all fields used by bnxt_aux_dev_release() are initialized. After auxiliary_device_init() succeeds, later errors must unwind with auxiliary_device_uninit(), which invokes the release callback. The release callback assumes that aux_priv->id, aux_priv->edev, edev->net and edev->ulp_tbl are all populated. If allocation fails after auxiliary_device_init(), the release path can otherwise dereference or clear partially initialized state. Allocate and attach the bnxt_en_dev and ULP table before calling auxiliary_device_init(), so the release callback only sees a fully initialized auxiliary private object. If auxiliary_device_init() itself fails, free those allocations directly because device_initialize() has not run and the release callback will not be invoked. 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-68382", "url": "https://ubuntu.com/security/CVE-2026-68382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Hold device ref until queue teardown completes GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock. Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending. Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work. With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. Replace the fini wait with an assertion and remove the unused fini_wq. v2: - Rebase v3: - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt) - Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt) - Drop separate deferred drm_dev_put worker. - Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini(). v4: - Replace the guc_submit_sw_fini() wait with an assertion and remove the now-unused fini_wq. (sashiko) v5: - Move destroy work to a module-lifetime Xe workqueue instead of system_dfl_wq. (Matt) - Flush the module-lifetime destroy workqueue during PCI remove to preserve the old device-remove wait semantics. v6: - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid letting it outlive the xe_device/drm_device. (Sashiko) - Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work can be queued from the reclaim path. v7: - Drop the per-device xe->destroy_wq and use the module-level destroy WQ for SVM pagemap destroy as well. (Matt) - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*() helpers because the WQ is no longer exec-queue specific. (Matt) v8: - Rebase. v9: - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM destroy_wq because it can be queued from reclaim and embeds the dev_pagemap used by devres teardown. (Sashiko) - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM from it. - Update the module-WQ kdoc to document the GuC/SVM split. v10: - Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the workqueue allocation warning. v11: - Drop the SVM pagemap destroy comment as it was revision-specific. (Thomas) v12: - Rebase. (cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68383", "url": "https://ubuntu.com/security/CVE-2026-68383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Keep scheduler timeline name alive The scheduler keeps a pointer to the timeline name, but q->name is freed with the exec queue while scheduler fences can still reference it. Store the name in struct xe_guc_exec_queue so it shares the scheduler's RCU-deferred lifetime. (cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68390", "url": "https://ubuntu.com/security/CVE-2026-68390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups hci_conn_params_lookup requires hdev->lock be held, otherwise the list iteration or param access is not safe. Hold hdev->lock for params lookups in hci_sync.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-2026-68404", "url": "https://ubuntu.com/security/CVE-2026-68404", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: use wiphy work for socket owner autodisconnect nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68367", "url": "https://ubuntu.com/security/CVE-2026-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: synchronize delayed set_alt with teardown The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68095", "url": "https://ubuntu.com/security/CVE-2026-68095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse-uring: fix race between registration and connection abortion This fixes this race: - thread a: io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref yet - thread b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() is a no-op due to queue ref being 0 - thread a: grabs the queue_ref, queue_ref is now 1, rest of fuse_uring_do_register() logic executes - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs and calls \"wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);\" The abort/unmount thread will hang indefinitely in unkillable state as nothing will decrement queue_refs or wake stop_waitq, and the ring, queue, and ent are leaked. Fix this by checking fch->connected under fch->lock after the created ent has grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either release the queue ref and wake up stop_waitq (in case fuse_chan_wait_aborted() is already waiting) in fuse_uring_do_register() when we detect !fch->connected, or if the connection is aborted after the check, it is guaranteed that the async teardown worker will be running in the background cleaning up ents and decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-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-68173", "url": "https://ubuntu.com/security/CVE-2026-68173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: wait on ublk_dev_ready() instead of ub->completion ub->completion is only re-armed by a successful START_USER_RECOVERY. If the ublk server sends END_USER_RECOVERY without one - e.g. its START failed with -EBUSY and the error was ignored - the wait is satisfied by the stale completion of the previous recovery cycle, and the device is marked LIVE and the requeue list kicked while the FETCH stream is still running and ubq->canceling is still set. The kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it again via __ublk_abort_rq(), and after the last FETCH clears ->canceling nothing ever kicks the requeue list again: the request is stranded there while holding its tag. If it is the flush machinery's flush_rq, every subsequent fsync piles up in uninterruptible sleep and teardown hangs on tag draining. This matches a report of a lost PREFLUSH with ext4 on top of ublk after daemon crash recovery. ub->completion is an edge-triggered latch used as a proxy for the level condition \"every queue has fetched all I/O commands\", which can regress (F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop it and wait on the real condition instead: the new helper ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then re-checks it under ub->mutex, waiting again on regression, and returns with the mutex held and readiness guaranteed. Readiness becomes true in the same ub->mutex critical section that clears the last queue's ->canceling, so END_USER_RECOVERY marks the device LIVE and kicks the requeue list strictly after ->canceling clears. The wait stays interruptible, so a server whose daemon died can still be signalled out. For ublk_ctrl_start_dev() this replaces the fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting until the device is ready again.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68113", "url": "https://ubuntu.com/security/CVE-2026-68113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68118", "url": "https://ubuntu.com/security/CVE-2026-68118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: challenge ACK for non-exact RST in SYN-RECEIVED The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-68120", "url": "https://ubuntu.com/security/CVE-2026-68120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtase: Workaround for TX hang caused by hardware packet parsing The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission.", "cve_priority": "medium", "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-68122", "url": "https://ubuntu.com/security/CVE-2026-68122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix peer refcount leak in TCP error paths When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&peer->tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object. The race window: CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error): ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2 schedule_work() <- queued schedule_work() <- NO-OP (work already pending) ovpn_tcp_peer_del_work runs: ovpn_peer_del() ovpn_peer_put() <- refcnt+1 <- peer never freed Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68128", "url": "https://ubuntu.com/security/CVE-2026-68128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: reject out-of-range ptype in ice_parser_profile_init set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from providing ptype >= 1024 through VIRTCHNL, resulting in a write past the end of the bitmap and a kernel page fault. Reproduced with a custom kernel module injecting a crafted VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1. crash_parser: ice_parser_profile_init @ ffffffffc0d61b60 crash_parser: setting ptype=0xffff (max valid=1023) crash_parser: calling ice_parser_profile_init -- expect OOB crash! BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace: ? __pfx_ice_parser_profile_init+0x10/0x10 [ice] crash_init+0x127/0xff0 [crash_parser] do_one_initcall+0x45/0x310 do_init_module+0x64/0x270 init_module_from_file+0xcc/0xf0 idempotent_init_module+0x17b/0x280 __x64_sys_finit_module+0x6e/0xe0 Bail out early with -EINVAL when ptype is out of range.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19: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-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-68132", "url": "https://ubuntu.com/security/CVE-2026-68132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: super: fix emergency thaw deadlock on frozen block devices do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68133", "url": "https://ubuntu.com/security/CVE-2026-68133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP Call Trace during PTP release If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will result in the following PTP release call trace during driver unload: kernel BUG at lib/list_debug.c:52! ice_ptp_release+0x332/0x3c0 [ice] ice_deinit_features.part.0+0x10e/0x120 [ice] ice_remove+0x100/0x220 [ice] This was observed when passing PF1 through to a VM. ice_ptp_init() fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT. Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and returning without error, preventing the invalid state transition to ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from ICE_PTP_RESETTING after a failed rebuild.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68134", "url": "https://ubuntu.com/security/CVE-2026-68134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: ptp_s390: Add missing facility check Only register the physical clock when facility 28 is installed and PTFF QAF returns that PTFF QPT is available.", "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-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-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-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-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-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-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-68150", "url": "https://ubuntu.com/security/CVE-2026-68150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/super: fix emergency thaw double-unlock of s_umount do_thaw_all() iterates over all superblocks via __iterate_supers() with SUPER_ITER_EXCL, which acquires s_umount exclusively before calling the callback and releases it afterwards. However, the callback do_thaw_all_callback() calls thaw_super_locked() which unconditionally releases s_umount on every code path. This results in a second unlock attempt in __iterate_supers() that corrupts the rwsem state, triggering a DEBUG_RWSEMS warning: [ 182.601148] sysrq: Emergency Thaw of all frozen filesystems [ 182.601865] ------------[ cut here ]------------ [ 182.602375] DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff99b1011e5870, owner = 0x0, curr 0xffff99b101b06c80, list not empty [ 182.603817] WARNING: kernel/locking/rwsem.c:1412 at up_write+0xa3/0x170, CPU#2: kworker/2:1/53 [ 182.604578] Modules linked in: [ 182.604864] CPU: 2 UID: 0 PID: 53 Comm: kworker/2:1 Not tainted 7.2.0-rc4-00001-gbd3bd93ea98a-dirty #4 PREEMPT(lazy) [ 182.605711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014 [ 182.606417] Workqueue: events do_thaw_all [ 182.606750] RIP: 0010:up_write+0xaf/0x170 [ 182.607076] Code: 19 3a 92 48 0f 44 c2 48 8b 55 08 48 8b 55 00 4c 8b 45 08 48 8b 55 00 48 8d 3d ad 91 e0 01 48 8b 4d 20 50 48 c7 c6 f0 8c 26 92 <67> 48 0f b9 3a e8 d7 93 4e 00 58 eb 81 48 83 7f 18 00 48 c7 c2 8d [ 182.608563] RSP: 0018:ffffb670001d7e08 EFLAGS: 00010246 [ 182.609007] RAX: ffffffff92349e8d RBX: 0000000000000000 RCX: ffff99b1011e5870 [ 182.609595] RDX: 0000000000000000 RSI: ffffffff92268cf0 RDI: ffffffff92914d10 [ 182.610283] RBP: ffff99b1011e5870 R08: 0000000000000000 R09: ffff99b101b06c80 [ 182.610847] R10: ffff99b10139a808 R11: fefefefefefefeff R12: 0000000000000000 [ 182.611414] R13: ffffffff90cf74d0 R14: 0000000000000000 R15: ffff99b1011e5800 [ 182.612009] FS: 0000000000000000(0000) GS:ffff99b1eaaee000(0000) knlGS:0000000000000000 [ 182.612670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 182.613146] CR2: 00000000005c631c CR3: 00000000013ee000 CR4: 00000000000006f0 [ 182.613722] Call Trace: [ 182.613946] [ 182.614130] __iterate_supers+0x128/0x150 [ 182.614463] do_thaw_all+0x1b/0x30 [ 182.614759] process_scheduled_works+0xbb/0x3f0 [ 182.615150] ? __pfx_worker_thread+0x10/0x10 [ 182.615499] worker_thread+0x129/0x270 [ 182.615816] ? __pfx_worker_thread+0x10/0x10 [ 182.616201] kthread+0xe2/0x120 [ 182.616469] ? __pfx_kthread+0x10/0x10 [ 182.616792] ret_from_fork+0x15b/0x240 [ 182.617115] ? __pfx_kthread+0x10/0x10 [ 182.617426] ret_from_fork_asm+0x1a/0x30 [ 182.617761] [ 182.617968] ---[ end trace 0000000000000000 ]--- [ 182.618412] Emergency Thaw complete Fix this by switching to SUPER_ITER_UNLOCKED and acquiring s_umount in the callback via super_lock_excl() before calling thaw_super_locked(). This matches the locking pattern expected by thaw_super_locked() and eliminates the double unlock. While at it, remove the dead 'return;' at the end of do_thaw_all_callback().", "cve_priority": "low", "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-68152", "url": "https://ubuntu.com/security/CVE-2026-68152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: fix use-after-free in AMT delayed works When an AMT device is removed, pending delayed works can still access the freed amt_dev structure, which may result in kernel crashes or memory corruption. amt_dev_stop() cancels req_wq and discovery_wq with cancel_delayed_work_sync(), but these works can be scheduled again from event_wq after the cancellation. This allows delayed works to access the freed amt_dev structure after the netdev has been released. The following is a simple race scenario: CPU0 CPU1 amt_dev_stop() cancel_delayed_work_sync() amt_event_work() mod_delayed_work(req_wq) free netdev req_wq accesses freed amt_dev Use disable_delayed_work_sync() in amt_dev_stop() to prevent req_wq and discovery_wq from being queued again and wait for running work items to complete. The delayed works are disabled after initialization in amt_newlink() and enabled only when the device is successfully opened. This keeps the delayed work lifecycle synchronized with the lifetime of the AMT device.", "cve_priority": "high", "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-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-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-68168", "url": "https://ubuntu.com/security/CVE-2026-68168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix afs_edit_dir_remove() to get, not find, block 0 Fix afs_edit_dir_remove() to use afs_dir_get_block() to get block 0 rather than afs_dir_find_block() as the latter caches the found block in the afs_dir_iter and may[*] switch out the page it's on if another afs_dir_find_block() is done. This parallels what afs_edit_dir_add() does. [*] There's more than one block per page.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68169", "url": "https://ubuntu.com/security/CVE-2026-68169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: userspace: fix use-after-free in get_local_id In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a \"not found\" sentinel.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68172", "url": "https://ubuntu.com/security/CVE-2026-68172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: make huge_ptep_get handled unaligned addresses huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma). The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned. On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map or into a hole, dereference a VA not mapped into the kernel pgtables and cause kernel panic. Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68174", "url": "https://ubuntu.com/security/CVE-2026-68174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix union collision of module and refcnt for dynamic events In 'struct trace_event_call', the 'module' pointer and the 'refcnt' atomic variable share the same memory space in a union. For dynamic events, the union member is 'refcnt', which acts as an active reference counter. When a dynamic event (such as kprobe, uprobe, fprobe, eprobe, or wprobe) has a non-zero reference count (e.g. due to active event triggers or perf attachments), its 'call->module' evaluates to a small non-zero integer instead of NULL. When filtering or setting events for a specific module (e.g., writing ':mod:' to 'set_event'), the code in '__ftrace_set_clr_event_nolock()' and 'update_event_fields()' reads 'call->module' directly without checking whether the event is dynamic. This causes the kernel to treat the small integer (refcnt) as a 'struct module' pointer, leading to a NULL/invalid pointer dereference (Oops) when dereferencing the module name. Fix this by ensuring that the 'TRACE_EVENT_FL_DYNAMIC' flag is checked before treating 'call->module' as a valid pointer in these code paths.", "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-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-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-68434", "url": "https://ubuntu.com/security/CVE-2026-68434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms Commit b1b4efea05a5 (\"serial: 8250_mid: Disable DMA for selected platforms\") replaced the dnv_board setup and exit callbacks with PTR_IF(false, ...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. Fix this by adding the missing NULL checks before calling the setup and exit callbacks.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17: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-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-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16: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-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-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-68198", "url": "https://ubuntu.com/security/CVE-2026-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix use-after-free in aggr_reset_state() The aggr_reset_state() function uses timer_delete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggr_module_destroy(). If the timer callback (aggr_timeout) is executing when aggr_reset_state() is called, the callback will continue to access aggr_conn fields like rx_tid[] and stat[] which may be freed immediately after by kfree(aggr_info->aggr_conn) in aggr_module_destroy(). Additionally, the timer callback can re-arm itself via mod_timer() while aggr_reset_state() is running, creating a more complex race condition. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "high", "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-68200", "url": "https://ubuntu.com/security/CVE-2026-68200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: don't re-enter an instance callback that is still running The userspace-driven timer (utimer) TRIGGER ioctl calls snd_timer_interrupt() directly with no serialization, so two threads triggering the same utimer can run snd_timer_interrupt() on one snd_timer concurrently. snd_timer_process_callbacks() drops timer->lock around each instance callback and marks the in-flight callback with the single SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that bit to drain an in-flight callback before freeing the instance. The bit cannot represent two concurrent callbacks: when a second interrupt re-queues an instance whose callback is still running, both run at once, the first to finish clears the bit, and the close-path drain then frees the instance (and its callback_data) while the other callback is still live - a use-after-free reachable by any user able to open /dev/snd/timer, both via a user timer instance and via a sequencer queue timer bound to the utimer. snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so a concurrent interrupt already observes it under the lock. Skip re-queuing an instance (and its slaves) to the ack/sack list while its callback is in flight; the accumulated pticks are delivered on the next tick, so no event is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68201", "url": "https://ubuntu.com/security/CVE-2026-68201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: drain a slave's callback before its master detaches it snd_timer_close_locked() drains the closing instance's own in-flight callback (IFLG_CALLBACK) before freeing it, but not its slaves'. When a master instance is closed, remove_slave_links() clears each slave's ->timer; the slave's own close then reads timer == NULL and takes the branch that skips the drain entirely (snd_timer_stop_slave() also no-ops on a NULL timer). So a slave whose callback is still running when the master is closed is freed underneath the live callback, leading to use-after-free. Drain the slaves too before remove_slave_links() severs them. snd_timer_stop() has already taken this instance off the active list, so no new slave callback can be queued. Take the slaves off the ack list so a pending one can't fire either, then wait for any that is already in flight.", "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-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-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-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-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-68211", "url": "https://ubuntu.com/security/CVE-2026-68211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32-dcmipp: 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. dcmipp_bytecap_start_streaming() returned -EINVAL when the source subdevice could not be resolved from the media graph, before pm_runtime_resume_and_get() and media_pipeline_start() had been called. The remaining error paths already converge on the err_buffer_done label, which calls dcmipp_bytecap_all_buffers_done(..., VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate err_pm_put / err_media_pipeline_stop 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": "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-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-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-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-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-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-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-68230", "url": "https://ubuntu.com/security/CVE-2026-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: amlogic-c3: Add validations for ae and awb config Avoid invalid memory access if the zones_num is bigger than zone_weight. This patch fixes the following smatch errors: drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max", "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-68232", "url": "https://ubuntu.com/security/CVE-2026-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path.", "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-68233", "url": "https://ubuntu.com/security/CVE-2026-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Shut down BO cache timer before teardown The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20: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-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-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-68238", "url": "https://ubuntu.com/security/CVE-2026-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Release VFCT ACPI table reference amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68239", "url": "https://ubuntu.com/security/CVE-2026-68239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Account for NULL and handle pages in ttm_pool_backup Pages in ttm_pool_backup can be NULL or backup handles (ttm_backup_page_ptr_is_handle()), neither of which can be passed to set_pages_array_wb() or freed. Add a dedicated WB pass before the dma/purge loop that walks allocations using the same i += num_pages stride, skipping NULL and handle entries, and calls set_pages_array_wb() once per contiguous run of real pages. Apply the same NULL/handle guard to the dma/purge loop. Fixes the following oops: Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI RIP: 0010:__cpa_process_fault+0xf8/0x770 RSP: 0018:ffffc90000a87718 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34 RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0 R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000 R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0 FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0 PKRU: 55555554 Call Trace: __change_page_attr_set_clr+0x989/0xe90 ? __purge_vmap_area_lazy+0x6c/0x3a0 ? _vm_unmap_aliases+0x250/0x2a0 set_pages_array_wb+0x7f/0x120 ttm_pool_backup+0x4c9/0x5b0 [ttm] ? dma_resv_wait_timeout+0x3b/0xf0 ttm_tt_backup+0x32/0x60 [ttm] ttm_bo_shrink+0x66/0x110 [ttm] xe_bo_shrink_purge+0x12b/0x1b0 [xe] xe_bo_shrink+0xbb/0x270 [xe] __xe_shrinker_walk+0xf7/0x160 [xe] xe_shrinker_walk+0x9d/0xc0 [xe] xe_shrinker_scan+0x11f/0x210 [xe] do_shrink_slab+0x13b/0x270 shrink_slab+0xf1/0x400 shrink_node+0x352/0x8a0 balance_pgdat+0x32c/0x700 kswapd+0x205/0x2f0 ? __pfx_autoremove_wake_function+0x10/0x10 ? __pfx_kswapd+0x10/0x10 kthread+0xd1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1b1/0x200 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68241", "url": "https://ubuntu.com/security/CVE-2026-68241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/mst: limit DP MST ESI service loop The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto. (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)", "cve_priority": "medium", "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-68245", "url": "https://ubuntu.com/security/CVE-2026-68245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only valid while the lock is still being held. Once xa_unlock_irqrestore is called and returned, the pointer is no longer under lock and is subject to modification. Since, the caller still dereferences vm->task_info in amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a use after unlock problem. Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid() through removing the amdgpu_vm_get_vm_from_pasid() function from amdgpu_vm.c and making the relevant code inline to hold the lock while it is still in use. (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)", "cve_priority": "high", "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-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-68252", "url": "https://ubuntu.com/security/CVE-2026-68252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68253", "url": "https://ubuntu.com/security/CVE-2026-68253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)", "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-68257", "url": "https://ubuntu.com/security/CVE-2026-68257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix 32-bit overflow in CWSR total size calculation total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68258", "url": "https://ubuntu.com/security/CVE-2026-68258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on CRIU restore queue type and mqd size We weren't checking whether the values provided in the private data in kfd CRIU restore were within bounds. For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it. For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations. (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)", "cve_priority": "low", "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-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-68266", "url": "https://ubuntu.com/security/CVE-2026-68266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68268", "url": "https://ubuntu.com/security/CVE-2026-68268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Return error on non-migratable faults requiring devmem Non-migratable faults that require devmem incorrectly jump to the 'out' label, which squashes the error code intended to be returned to the upper layers. Fix this by returning -EACCES instead. (cherry picked from commit c4508edb2c723de93717272488ea65b165637eac)", "cve_priority": "medium", "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-68270", "url": "https://ubuntu.com/security/CVE-2026-68270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Avoid possible truncation with calculating visible size Calculating the visible size of the system framebuffer can result in truncation of the result. The calculation uses 32-bit arithmetics, which can overflow if the values for height and stride are large. Fix the issue by multiplying with mul_u32_u32().", "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-68275", "url": "https://ubuntu.com/security/CVE-2026-68275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks up the bo_va for the buffer object in the caller's VM via amdgpu_vm_bo_find(), but uses the returned pointer without checking it. amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM, which is the normal case for a BO that has never been mapped. The result is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which expands to list_for_each_entry(mapping, &(bo_va)->valids, list) and dereferences bo_va, causing a NULL pointer dereference. This is reachable by any process able to issue the ioctl (render group) simply by requesting mapping info for an unmapped BO. Return -ENOENT when no bo_va is found, jumping to out_exec so the drm_exec context and GEM object reference are released. (cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68276", "url": "https://ubuntu.com/security/CVE-2026-68276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx: fix cleaner shader IB buffer overflow The cleaner shader sysfs path allocates a 16-dword (64 byte) IB but incorrectly fills (align_mask + 1) dwords. On GFX rings align_mask is 0xff, so the loop wrote 256 dwords into a 64-byte buffer, causing a kernel page fault. The IB only needs to be a minimal NOP shell to schedule the job; the cleaner shader itself is emitted on the ring via emit_cleaner_shader(). Fill 16 dwords to match the allocation. v2: Use ib_size_dw variable (Lijo) (cherry picked from commit bf21af331ebf72d0935fd70c73192414a422c03a)", "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-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-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-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-68282", "url": "https://ubuntu.com/security/CVE-2026-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: analogix_dp: Add missing error check for platform_get_resource() Add missing error check for platform_get_resource() return value to prevent NULL pointer dereference when memory resource is not available.", "cve_priority": "medium", "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-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-68292", "url": "https://ubuntu.com/security/CVE-2026-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues.", "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-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-68296", "url": "https://ubuntu.com/security/CVE-2026-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM Before commit 00d066a4d4ed (\"netdev_features: convert NETIF_F_LLTX to dev->lltx\"), NETIF_F_LLTX was set unconditionally in both __gre_tunnel_init() and ip6gre_tnl_init_features() alongside GRE_FEATURES: dev->features |= GRE_FEATURES | NETIF_F_LLTX; When that commit converted NETIF_F_LLTX to the dev->lltx flag, it placed 'dev->lltx = true' after the SEQ/CSUM early returns instead of before them. This causes GRE/GRETAP/ip6gre tunnels with SEQ or CSUM+encap to lose lockless TX, reintroducing _xmit_lock acquisition around their ndo_start_xmit. Since GRE xmit re-enters the stack via ip_tunnel_xmit(), holding _xmit_lock risks ABBA deadlock with the underlay device. CPU0 CPU1 ---- ---- lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); Fix by moving dev->lltx = true before the early returns in both functions, restoring the original unconditional behavior.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64575", "url": "https://ubuntu.com/security/CVE-2026-64575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: fix double sock release on batch realloc bpf_iter_tcp_batch() releases the current batch via bpf_iter_tcp_put_batch(), which drops the socket refs and rewrites each slot with the socket cookie, then grows the batch. cur_sk/end_sk are kept for bpf_iter_tcp_resume(), but on realloc failure the function returns ERR_PTR() before resume runs, leaving cur_sk < end_sk over slots that now hold cookies rather than sock pointers. bpf_iter_tcp_seq_stop() then calls bpf_iter_tcp_put_batch() again and dereferences a cookie as a struct sock. Empty the batch on the failure path so stop() does not release it again. The sockets were already freed by the first bpf_iter_tcp_put_batch(), so nothing leaks, and a later read() rescans the bucket from the start instead of skipping it. The sibling GFP_NOWAIT failure path still holds real socket references and is left for stop() to release. BUG: KASAN: null-ptr-deref in __sock_gen_cookie Read of size 8 at addr 0000000000000059 by task exploit ... __sock_gen_cookie (net/core/sock_diag.c:28) bpf_iter_tcp_put_batch (net/ipv4/tcp_ipv4.c:2918) bpf_iter_tcp_seq_stop (net/ipv4/tcp_ipv4.c:3270) bpf_seq_read (kernel/bpf/bpf_iter.c:205) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 entry_SYSCALL_64_after_hwframe Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16: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-68298", "url": "https://ubuntu.com/security/CVE-2026-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create() Commit 9e9787414882 (\"drm/xe/userptr: replace xe_hmm with gpusvm\") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a \"simple\" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). (cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4)", "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-68448", "url": "https://ubuntu.com/security/CVE-2026-68448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: check access to copy_file_range source with src mounter creds Commit 5dae222a5ff0c (\"vfs: allow copy_file_range to copy across devices\") allowed filesystems that implement the copy_file_range() f_op to decide if they want to access cross-sb copy from/to the same fs type. The same commit added checks to verify same sb copy for filesystems that implement ->copy_file_range() and do not support cross-sb copy at the time, namely, to ceph, fuse and nfs. The two remaining fs which implement ->copy_file_range(), cifs and overlayfs started to support cross-sb copy from this time. While overlayfs does support cross-sb copy when the two underlying files are on the same base fs, the copy operation on the two real files from two different overalyfs filesystems is performed with the mounter creds of the destination overlayfs and the read permission access hook for the source file was called with the wrong creds. This could cause either deny of access to copy which would otherwise be allowed (e.g. with splice) or allow read access to file which would otherwise be denied. Fix the latter case by explicitly verifying read access to source file with the source overlayfs mounter creds. The former case remains a quirk of cross-sb overlayfs copy, but userspace could fall back to regular copy so no harm done.", "cve_priority": "low", "cve_public_date": "2026-08-12 01:17: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-68307", "url": "https://ubuntu.com/security/CVE-2026-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix crash in reset link replay During reset recovery, mt7925_vif_connect_iter() replays firmware state for links tracked in mvif->valid_links. After MLO link changes or MCU timeout recovery, the driver bitmap can temporarily contain a link whose mac80211 bss_conf has already gone away. This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching the crash where x1, the second argument, is NULL: pc : mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] lr : mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] x2 : ffffff80a77f6018 x1 : 0000000000000000 x0 : ffffff8099402080 Call trace: mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common] Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA reset replay is unchanged because the helper still returns &vif->bss_conf for the legacy link.", "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-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-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-68311", "url": "https://ubuntu.com/security/CVE-2026-68311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: guard link STA in decap offload mt7925_sta_set_decap_offload() iterates over the vif valid_links mask when updating decap offload state for an MLO station. The station may not have a link STA for every valid link of the vif, so mt792x_sta_to_link() can return NULL for a link that belongs to the vif but not to the station. The function currently dereferences mlink before checking whether the link WCID is ready. If mlink is NULL, setting or clearing MT_WCID_FLAG_HDR_TRANS dereferences a NULL pointer. Skip links without a station link before touching mlink->wcid.", "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-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-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-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-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-68321", "url": "https://ubuntu.com/security/CVE-2026-68321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix FDIR filter leak on remove Perfect FDIR filters can be added while the interface is down and are kept on the software list for later restore. unregister_netdev() only calls ndo_stop when the device is up, so txgbe_fdir_filter_exit() in txgbe_close() is skipped in that case and the filters are leaked on driver remove. Free the filter list from txgbe_remove() as well.", "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-68330", "url": "https://ubuntu.com/security/CVE-2026-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix DMA direction for NPU mailbox buffer airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE, but some callers expect the NPU to write response data back into the same buffer: - airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into the buffer, then the caller reads it via memcpy() - airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back npu_stats_addr field in the response On non-cache-coherent architectures like EN7581 (Cortex-A53 without hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op — it does not invalidate the CPU cache. If the NPU-written cache line is still present in the CPU cache when the caller reads the buffer, the CPU observes stale data instead of the NPU response. This is a timing-sensitive bug: small mailbox buffers (~24 bytes) typically fit in a single cache line and may survive in the cache until the caller reads them, producing silent data corruption rather than a crash. The bug is more likely to trigger when the caller reads the response immediately after dma_unmap_single() without intervening cache-evicting operations. Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures dma_unmap_single() invalidates the CPU cache on non-coherent systems. The mailbox buffers are small so there is no performance concern.", "cve_priority": "low", "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-68332", "url": "https://ubuntu.com/security/CVE-2026-68332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix potential use-after-free in airoha_ppe_deinit() airoha_ppe_deinit() replaces the NPU pointer with NULL via rcu_replace_pointer() but does not wait for existing RCU readers to exit before calling ppe_deinit() and airoha_npu_put(). This can cause a use-after-free if a reader in an RCU read-side critical section still holds a reference to the NPU when it is freed. The init path (airoha_ppe_init) already calls synchronize_rcu() after rcu_assign_pointer(), but the deinit path introduced in commit 6abcf751bc08 (\"net: airoha: Fix schedule while atomic in airoha_ppe_deinit()\") omitted the matching barrier when switching from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer(). Add synchronize_rcu() before ppe_deinit() to ensure all existing RCU readers have completed before the NPU resources are released.", "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-68334", "url": "https://ubuntu.com/security/CVE-2026-68334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix io_thread race in rxrpc_wake_up_io_thread() rxrpc_wake_up_io_thread() checks local->io_thread before waking it, but then reloads the pointer for wake_up_process(). local->io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so the second load can see NULL even if the first load did not. Take a READ_ONCE() snapshot and use it for both the NULL check and the wake_up_process() call, as rxrpc_encap_rcv() already does.", "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-68341", "url": "https://ubuntu.com/security/CVE-2026-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: fix use after free in unlock_ovpn() unlock_ovpn() iterates over the release_list using llist_for_each_entry() and drops the peer reference inside the loop body via ovpn_peer_put(). If this drops the last reference, the peer is eventually freed. However, llist_for_each_entry() reads peer->release_entry.next in the loop advance expression, which runs after the body. By that time the peer may have already been freed, resulting in a use after free when advancing to the next list entry. Fix this by using llist_for_each_entry_safe(), which caches the next pointer before executing the loop body.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68342", "url": "https://ubuntu.com/security/CVE-2026-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovpn: avoid putting unrelated P2P peer on socket release ovpn_peer_release_p2p() is called when an OVPN UDP socket is being destroyed. It checks the currently published P2P peer and releases it only if that peer still uses the socket being destroyed. A peer replacement can publish a new peer before the old UDP socket is destroyed. When the old socket destruction path runs afterwards, ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the new peer uses a different socket, the function takes the socket mismatch branch. That branch still calls ovpn_peer_put(peer). At this point, however, peer is the currently published replacement peer, not the peer associated with the socket being destroyed. Dropping its reference can free it while ovpn->peer still points to it, leading to later use-after-free accesses from the peer and socket cleanup paths. KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer object. In the reproducer, the object is allocated from ovpn_peer_new() via ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU callback processing. Observed access sites include ovpn_peer_remove(), ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn(). Fix this by returning from the socket mismatch branch without putting the peer.", "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-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-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-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-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-68356", "url": "https://ubuntu.com/security/CVE-2026-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: airoha: Prevent division by zero when clock frequency is zero clk_get_rate() can return 0 when the clock provider is not properly configured or the clock is unmanaged. The driver uses wdt_freq as a divisor directly in airoha_wdt_probe() to compute max_timeout and in airoha_wdt_get_timeleft() to compute the remaining time, which results in a division by zero. Add a check for wdt_freq == 0 in probe and return -EINVAL with dev_err_probe() to prevent the division by zero and provide a diagnostic message.", "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-68358", "url": "https://ubuntu.com/security/CVE-2026-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-kraken3) 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-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-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-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-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-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-68374", "url": "https://ubuntu.com/security/CVE-2026-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: sysfs: add lock to bos_descriptors_read() Add a lock to the function bos_descriptors_read(). This function accesses udev->bos, which could be simultaneously freed in usb_reset_and_verify_device(), a function that is commonly called in drivers all over the kernel.", "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-68378", "url": "https://ubuntu.com/security/CVE-2026-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions: - A pin is registered with two or more dpll devices (dpll_A, dpll_B) - The pin has ref_sync pairs with other pins - During unregistration of dpll_A's pins, a ref_sync partner pin is unregistered first, removing it from dpll_A->pin_refs - But since the partner pin is still registered with dpll_B, its dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT run and the partner stays in the pin's ref_sync_pins xarray - When the pin itself is then unregistered from dpll_A, the delete notification calls dpll_msg_add_pin_ref_sync() which finds the partner in ref_sync_pins, passes dpll_pin_available() (partner is still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A, partner) returns NULL because partner was already removed from dpll_A->pin_refs - The NULL priv pointer is passed to the driver's ref_sync_get callback, which dereferences it BUG: kernel NULL pointer dereference, address: 0000000000000034 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x] Call Trace: dpll_msg_add_pin_ref_sync+0xb8/0x200 dpll_cmd_pin_get_one+0x3b6/0x4b0 dpll_pin_event_send+0x72/0x140 __dpll_pin_unregister+0x5a/0x2b0 dpll_pin_unregister+0x49/0x70 Fix this by skipping ref_sync pins whose priv pointer cannot be resolved for the current dpll device.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68379", "url": "https://ubuntu.com/security/CVE-2026-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix TIME_WAIT socket reference leak on PSP policy failure Release the TIME_WAIT socket reference and jump to discard_it upon PSP policy failure in both IPv4 and IPv6 receive paths. This prevents a memory leak of tcp_tw_bucket structures.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68380", "url": "https://ubuntu.com/security/CVE-2026-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix use-after-free of mm_struct in job scheduler amdxdna_cmd_submit() stores current->mm in job->mm without holding any reference. aie2_sched_job_run() later access job->mm from the DRM scheduler worker thread. With only a raw pointer and no structural reference, the mm_struct can be freed before the scheduler runs the job. Fix this by calling mmgrab() to hold a structural mm_count reference for the lifetime of the job, paired with mmdrop() in every cleanup path.", "cve_priority": "high", "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-68384", "url": "https://ubuntu.com/security/CVE-2026-68384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits. - Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it. While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one. (cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68385", "url": "https://ubuntu.com/security/CVE-2026-68385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/checksum: Fix csum_partial() without vector facility Currently csum_partial() calls csum_copy() with copy=false and dst=NULL. On machines without the vector facility, csum_copy() falls back to cksm(dst, ...), causing the checksum to be calculated from address zero instead of the source buffer. The VX implementation already checksums data loaded from src. Make the fallback do the same by passing src to cksm().", "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-68387", "url": "https://ubuntu.com/security/CVE-2026-68387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: add locking for raw flags bitfield With commit 890e5198a6e5 (\"can: raw: use bitfields to store flags in struct raw_sock\") the formerly separate integer values have been integrated into a single bitfield. This led to a read-modify-write operation when changing a flag in raw_setsockopt() which now needs a locking to prevent concurrent access. Instead of adding a lock/unlock hell in each of the flag manipulations this patch introduces a wrapper for a new raw_setsockopt_locked() function analogue to the isotp_setsockopt[_locked]() approach in net/can/isotp.c [mkl: use Closes tag instead of Link]", "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-68393", "url": "https://ubuntu.com/security/CVE-2026-68393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: extend conn_hash lookup critical sections Using RCU-protected pointers outside the critical sections without refcount is incorrect and may result to UAF. Extend critical section to cover both hci_conn_hash lookup and use of the returned conn. Add surrounding rcu_read_lock() also when return value is not used, in preparation for RCU lockdep requirement to hci_lookup_le_connect(). This avoids concurrent deletion of the conn before we are done dereferencing it. Also, make sure to hold hdev->lock when accessing hdev->accept_list.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68394", "url": "https://ubuntu.com/security/CVE-2026-68394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update MGMT_OP_LOAD_CONN_PARAM queues conn_update_sync() when a single parameter update changes an existing LE central connection. The queued work currently stores a borrowed hci_conn_params entry from hdev->le_conn_params. A later LOAD_CONN_PARAM request can clear disabled parameters and free that entry before hci_cmd_sync_work() runs the queued callback. Do not keep the borrowed hci_conn_params pointer in queued work. Queue the hci_conn instead and hold a reference until the queued callback completes. When the work runs, revalidate that the connection is still present, look up the current hci_conn_params entry, and cancel the update if userspace removed that entry while the work was pending. Copy the interval values from the current params entry under hdev->lock, then drop the lock and keep using hci_le_conn_update_sync() to issue the update. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in conn_update_sync+0x2a/0xf0 [bluetooth] Read of size 1 at addr ffff88810c697126 by task kworker/u17:0/377 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 kasan_report+0xe0/0x110 conn_update_sync+0x2a/0xf0 [bluetooth] hci_cmd_sync_work+0x187/0x210 [bluetooth] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 Allocated by task 466: hci_conn_params_add+0xa6/0x240 [bluetooth] load_conn_param+0x4e1/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] Freed by task 474: kfree+0x313/0x590 hci_conn_params_clear_disabled+0x9b/0xc0 [bluetooth] load_conn_param+0x4bf/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth]", "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-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-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-68400", "url": "https://ubuntu.com/security/CVE-2026-68400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint memory access array and to comply with the FF-A spec instead of defaulting to `sizeof(struct ffa_mem_region)`. This requires moving `ffa_mem_region_additional_setup()` earlier in the setup flow. Also, add sanity checks to ensure the calculated descriptor offsets do not exceed `max_fragsize`.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68401", "url": "https://ubuntu.com/security/CVE-2026-68401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() Sashiko (locally) reports multiple out-of-bound issues in ffa_setup_and_transmit: 1) Writing ep_mem_access->reserved can write out of bounds for FFA versions < 1.2 as ffa_emad_size_get() returns 16 bytes in that case while reserved has an offset of 24. Instead of zeroing fields, memset the struct to zero first based on the FFA version. 2) Make sure there is enough size to write constituents. While at it, convert the only sizeof() in the driver that uses a type instead of variable.", "cve_priority": "high", "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-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-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-68409", "url": "https://ubuntu.com/security/CVE-2026-68409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: defer link RX stats percpu free to RCU sta_remove_link() frees a removed MLO link's RX stats percpu buffer right away, but defers only the link container to RCU: \tsta_info_free_link(&alloc->info); \tkfree_rcu(alloc, rcu_head); The RX fast path reads link_sta under rcu_read_lock and writes the percpu stats. A reader that resolved link_sta before the removal keeps the pointer. The container stays alive from the kfree_rcu, so the read still works. But the percpu block it points to is already freed. This needs uses_rss. That is when pcpu_rx_stats exists. The full STA teardown frees the deflink stats only after synchronize_net(). The link removal path had no such barrier. The race is hard to win in practice, but the free should still wait for RCU. Free the link together with its data from a single RCU callback, so the percpu block is reclaimed only after readers drain.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20: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-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-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-68412", "url": "https://ubuntu.com/security/CVE-2026-68412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan() If the test against IEEE80211_MAX_SSID_LEN fails, then 'creq' leaks. Use the existing error handling path to fix it.", "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-64566", "url": "https://ubuntu.com/security/CVE-2026-64566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags() When iptfs_skb_add_frags() copies frag references from the source frag walk into a new SKB, it increments the page reference count via __skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the destination SKB's skb_shinfo->flags. If the source SKB carries shared frags (e.g. from a page-pool backed receive path), the new inner SKB will appear to ESP as having privately owned frags. A subsequent esp_input() call for a nested transport-mode SA then takes the no-COW fast path and decrypts in place, writing over pages that are still referenced by the outer IPTFS SKB. This causes kernel-visible memory corruption and can trigger a panic. All other frag-transfer helpers in the kernel (skb_try_coalesce, skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this convention by setting the flag inside the loop immediately after __skb_frag_ref() and nr_frags++, so every exit path that attaches a frag unconditionally propagates SKBFL_SHARED_FRAG.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68415", "url": "https://ubuntu.com/security/CVE-2026-68415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear mode callbacks after failed mode setup xfrm_state_gc_task can run long after a failed IPTFS state setup. In the reproduced case, __xfrm_init_state() cached x->mode_cbs, IPTFS setup returned -ENOMEM before publishing mode_data, and the temporary module reference from xfrm_get_mode_cbs() was dropped immediately. The dead state then kept x->mode_cbs until deferred GC ran after xfrm_iptfs had been unloaded. Clear x->mode_cbs when mode init or clone fails before publishing mode_data. Those states never installed mode-specific state or the long-term IPTFS module pin, so deferred GC has nothing mode-specific to destroy and must not retain a callback table pointer past the temporary lookup reference. The buggy scenario involves two paths, with each column showing the order within that path: failed setup path: 1. cache x->mode_cbs 2. mode setup fails before mode_data 3. drop the temporary module ref 4. dead state keeps x->mode_cbs cached GC/unload path: 1. xfrm_state_put() queues GC work 2. xfrm_iptfs unloads later 3. xfrm_state_gc_task runs 4. GC dereferences stale x->mode_cbs This also covers the failed clone path where clone_state() returns before publishing mode_data. Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y failslab_stacktrace_filter matched xfrm_iptfs frames ack_error=-12 FAULT_INJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrm_state_gc_task RIP: xfrm_state_gc_task+0x142/0x650 Modules linked in: esp4_offload xfrm_user [last unloaded: xfrm_iptfs] Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-68418", "url": "https://ubuntu.com/security/CVE-2026-68418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent user-triggered null deref on QP create Previously, the user QP creation path would only attempt to populate iwqp->iwpbl if the user-provided req.user_wqe_bufs field was non-zero. The problem is that iwqp->iwpbl is unconditionally dereferenced later on in irdma_setup_virt_qp. While there was a check for iwqp->iwpbl != NULL, this check would only occur if req.user_wqe_bufs was non-zero. The end result is that a user could send a zero user_wqe_bufs value and trigger a null ptr deref. Fix this by unconditionally calling irdma_get_pbl and bailing if it fails, similar to the CQ and SRQ paths.", "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-68420", "url": "https://ubuntu.com/security/CVE-2026-68420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: reject optional IPTFS templates in outbound policies syzbot reported a stack-out-of-bounds read in xfrm_state_find() which flows from xfrm_tmpl_resolve_one(). Commit 3d776e31c841 (\"xfrm: Reject optional tunnel/BEET mode templates in outbound policies\") disallowed optional tunnel and BEET in outbound policies to prevent this. Later when IPTFS added, it was not covered by that fix and can still trigger the out-of-bounds read; Extend the check to disallow optional IPTFS in outbound policies as well. IPTFS should be identical to tunnel mode. IN and FWD policies are not affected: xfrm_tmpl_resolve_one() is only reachable via the outbound path. Reproducer, before: ip link add dummy0 type dummy ip link set dummy0 up ip addr add 10.1.1.1/24 dev dummy0 ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 mode transport ping -W 1 -c 1 10.1.1.2 PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data. [ 64.168420] ================================================================== [ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844 [ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full) [ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 64.169977] Call Trace: [ 64.169977] [ 64.169977] dump_stack_lvl+0x47/0x70 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] print_report+0x152/0x4b0 [ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0 [ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20 [ 64.169977] ? __virt_addr_valid+0x21b/0x230 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] kasan_report+0xa8/0xd0 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm_dst_hash+0x24/0xc0 [ 64.169977] xfrm_state_find+0xa2d/0x2f90 [ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570 [ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10 [ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 64.169977] ? kernel_text_address+0x5b/0x80 [ 64.169977] ? __kernel_text_address+0xe/0x30 [ 64.169977] ? unwind_get_return_address+0x5e/0x90 [ 64.169977] ? arch_stack_walk+0x8c/0xe0 [ 64.169977] xfrm_tmpl_resolve+0x130/0x200 [ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10 [ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110 [ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10 [ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310 [ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80 [ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10 [ 64.169977] ? ip_route_output_key_hash+0xc6/0x110 [ 64.169977] ? kasan_save_track+0x10/0x30 [ 64.169977] xfrm_lookup_route+0x18/0xe0 [ 64.169977] ip4_datagram_release_cb+0x4c9/0x530 [ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10 [ 64.169977] ? do_raw_spin_lock+0x71/0xc0 [ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 64.169977] release_sock+0xb0/0x170 [ 64.169977] udp_connect+0x43/0x50 [ 64.169977] __sys_connect+0xa6/0x100 [ 64.169977] ? alloc_fd+0x2e9/0x300 [ 64.169977] ? __pfx___sys_connect+0x10/0x10 [ 64.169977] ? preempt_latency ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68421", "url": "https://ubuntu.com/security/CVE-2026-68421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx() put_prev_task_scx() warns when a runnable task drops to a lower sched_class without SCX_OPS_ENQ_LAST, on the assumption that balance_one() would have kept it running. Core scheduling breaks that: a forced-idle SMT sibling reschedules through the core_pick fast path in pick_next_task(), which skips pick_task_scx() and thus balance_one(), so a runnable task can drop to idle with ENQ_LAST unset. Gate the warning on sched_cpu_cookie_match(): a cookie mismatch means core scheduling forced the idle, while a match (or core scheduling off) still catches a genuine missing-ENQ_LAST drop.", "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-68426", "url": "https://ubuntu.com/security/CVE-2026-68426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix stale skb->prev after async crypto steals a GSO segment skb_gso_segment() leaves the segment list head with ->prev pointing at the last segment, an invariant validate_xmit_skb_list() relies on when it sets its tail pointer (tail = skb->prev). When validate_xmit_xfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validate_xmit_skb_list() later does tail->next = skb, writing through that stale pointer -- a use-after-free. Repoint skb->prev at the last retained segment before returning.", "cve_priority": "critical", "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-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-2023-20585", "url": "https://ubuntu.com/security/CVE-2023-20585", "cve_description": "Insufficient checks of the RMP on host buffer access in IOMMU may allow an attacker with privileges and a compromised hypervisor to trigger an out of bounds condition without RMP checks, resulting in a potential loss of confidential guest integrity.", "cve_priority": "low", "cve_public_date": "2026-04-16 19:16:00 UTC" }, { "cve": "CVE-2026-68364", "url": "https://ubuntu.com/security/CVE-2026-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix ISM dc_lock deadlock during suspend [Why] System hang observed during suspend/resume while video is playing. amdgpu_dm_ism_disable() is called under dc_lock and waits for ISM delayed work via disable_delayed_work_sync(). The work handlers themselves take dc_lock, producing an ABBA deadlock when a worker is in flight at suspend time. [How] Split the disable path into two phases with opposite locking contracts: 1. amdgpu_dm_ism_disable() -- quiesces workers, must NOT hold dc_lock. 2. amdgpu_dm_ism_force_full_power() (new) -- drives the ISM FSM back to FULL_POWER_RUNNING, must hold dc_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72064", "url": "https://ubuntu.com/security/CVE-2026-72064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Sync page pool RX frags for CPU MANA allocates RX buffers from page pool fragments when frag_count is greater than 1. In that case the buffers remain DMA mapped by page pool and the RX completion path does not call dma_unmap_single(). As a result, the implicit sync-for-CPU normally performed by dma_unmap_single() is missing before the packet data is passed to the networking stack. This breaks RX on configurations which require explicit DMA syncing, for example when booted with swiotlb=force. Fix this by recording the page pool page and DMA sync offset when the RX buffer is allocated, and syncing the received packet range for CPU access before handing the RX buffer to the stack.", "cve_priority": "medium", "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-72098", "url": "https://ubuntu.com/security/CVE-2026-72098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-verity: fix buffer overflow in FEC calculation There's a buffer overflow in dm-verity-fec: if (neras && *neras <= v->fec->roots) \tfio->erasures[(*neras)++] = i; This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72248", "url": "https://ubuntu.com/security/CVE-2026-72248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: support IPIP tunnel with direct xmit The combination of IPIP tunnel with direct xmit, eg. bridge device, breaks because no dst_entry is provided to check the skb headroom and to set the iph->frag_off field. This leads to invalid dst usage and can trigger a crash in the tunnel transmit path. Fix this by moving dst_cache and dst_cookie out of the runtime union so that they can be shared by neighbour, xfrm, and direct tunnel flows. For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve route state in these shared fields and release it through the common dst release path. Since dst_entry is now available to the three supported xmit modes and dst_release() already deals with NULL dst, remove the xmit type check in nft_flow_dst_release(). Moreover, skip the check if the dst entry is NULL in nf_flow_dst_check() which is now the case for the direct xmit case. Based on patch from Rein Wei .", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72249", "url": "https://ubuntu.com/security/CVE-2026-72249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: use dst in this direction when pushing IPIP header When pushing the IPIP header, the route of the other direction is used to calculate the headroom, use the route in this direction. Accessing the other tuple to set the IP source and destination is fine because this tuple does not provide such information to avoid storing redundant information. However, this tuple already provides the dst for this direction, this went unnoticed because this bug affects headroom and iph->frag_off only at this stage.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72287", "url": "https://ubuntu.com/security/CVE-2026-72287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the \"normal\" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a \"late\" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72329", "url": "https://ubuntu.com/security/CVE-2026-72329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/liquidio: drop cached VF pci_dev LUT The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST. Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72355", "url": "https://ubuntu.com/security/CVE-2026-72355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix barriering when walking subrequest list Fix the barriering used when walking the subrequest list in retry as there's a possibility of seeing a subreq that's just been added by the application thread.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72412", "url": "https://ubuntu.com/security/CVE-2026-72412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/mm: Fix handling of _PAGE_UNUSED pte bit The _PAGE_UNUSED softbit should not really be lying around. Its sole purpose is to signal to try_to_unmap_one() and try_to_migrate_one() that the page can be discarded instead of being moved / swapped. KVM has no way to know why a page is being unmapped, so it sets the bit on userspace ptes corresponding to unused guest pages every time they get unmapped. KVM has no reasonable way to clear the bit once the page is in use again. While set_ptes() checks and clears the bit, other paths that set new ptes did not. This led to used pages being thrown out as if they were unused, causing guest corruption. Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in set_pte(), i.e. whenever a present pte is getting set. The check in set_ptes() is then redundant and can be removed. Also fix gmap_helper_try_set_pte_unused() to only set the bit if the pte is present; the _PAGE_UNUSED bit is only defined for present ptes and thus should not be set for non-present ptes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72417", "url": "https://ubuntu.com/security/CVE-2026-72417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto() Add sanity check for iph->ihl field in nf_flow_ip4_tunnel_proto() before using it to compute the header size, avoiding out-of-bounds access with malformed IP headers. While at it, use iph->protocol instead of the hardcoded IPPROTO_IPIP constant when setting ctx->tun.proto and reference ctx->tun.hdr_size when updating ctx->offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72442", "url": "https://ubuntu.com/security/CVE-2026-72442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: fix and simplify IP6IP6 tunnel handling Fix nf_flow_ip6_tunnel_proto() to use pskb_may_pull() instead of skb_header_pointer() to ensure the outer IPv6 header is in the skb headroom, which is required for subsequent packet processing. Move ctx->offset update inside the IPPROTO_IPV6 conditional block since it should only be adjusted when an IP6IP6 tunnel is actually detected. Simplify the rx path by removing ipv6_skip_exthdr() and checking ip6h->nexthdr directly, as the flowtable fast path only handles simple IP6IP6 encapsulation without extension headers. Drop the tunnel encapsulation limit destination option support from the tx path to match, since the rx path no longer handles extension headers. Remove the encap_limit parameter from nf_flow_offload_ipv6_forward(), nf_flow_tunnel_ip6ip6_push() and nf_flow_tunnel_v6_push(), along with the ipv6_tel_txoption struct and related headroom/MTU adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72463", "url": "https://ubuntu.com/security/CVE-2026-72463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix dev use-after-free in xfrm async resumption xfrm async resumption hold skb->dev refcnt until after transport_finish. However, xfrm_rcv_cb may modify skb->dev to tunnel dev without taking device reference, such as vti_rcv_cb. The subsequent async resumption will decrement the tunnel device's reference count, which lead to uaf of tunnel dev and refcnt leak of orig dev as below: unregister_netdevice: waiting for vti1 to become free. Usage count = -2 Stash the original skb->dev to fix refcnt imbalance. The new skb->dev set by xfrm_rcv_cb can race with device teardown. Extend rcu protection over xfrm_rcv_cb and transport_finish to prevent races.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72477", "url": "https://ubuntu.com/security/CVE-2026-72477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: call _ntfs_bad_inode() when failing to rename It is safe to call _ntfs_bad_inode on live inodes since: commit 519b078998ce (\"fs/ntfs3: Exclude call make_bad_inode for live nodes.\") The WARN_ON was added when it wasn't safe by: commit d99208b91933 (\"fs/ntfs3: cancle set bad inode after removing name fails\") Replace the WARN_ON with a call to _ntfs_bad_inode() to prevent further operations on the inconsistent inode.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72493", "url": "https://ubuntu.com/security/CVE-2026-72493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: serialize netif_running() check in enqueue_to_backlog() Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup(). The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit). Commit e9e4dd3267d0 (\"net: do not process device backlog during unregistration\") introduced a lockless netif_running() check in enqueue_to_backlog() to prevent queuing packets to an unregistering device. However, this creates a TOCTOU race window. A lockless transmitter (like veth_xmit) can pass the check before dev_close() clears IFF_UP. If the transmitter is then delayed, flush_all_backlogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed. Fix this by moving the netif_running() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netif_running() after the flush/close completes (so it gets dropped).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72494", "url": "https://ubuntu.com/security/CVE-2026-72494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Replace waitqueue and flag with completion The driver previously used a waitqueue along with an explicit request_done flag, but without proper barriers around request_done. An earlier patch by Gui-Dong Han attempted to fix this by adding the missing memory barriers. Rather than adding the barriers, this patch replaces the waitqueue+flag with a completion, which is designed for this exact purpose.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72496", "url": "https://ubuntu.com/security/CVE-2026-72496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Proper rollback if the ioremap fails bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74269", "url": "https://ubuntu.com/security/CVE-2026-74269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt: fix head underflow on XDP head-grow The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free. The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with this commit applied causes the test to run successfully to completion. The other rx_skb_func implementations don't have this issue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74350", "url": "https://ubuntu.com/security/CVE-2026-74350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate fast symlink target during inode read ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment. A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer. Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated. This keeps malformed fast symlinks from reaching the read path. Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x19f/0x330 (?:?) kasan_report+0xe0/0x110 (?:?) kasan_check_range+0x105/0x1b0 (?:?) __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72495", "url": "https://ubuntu.com/security/CVE-2026-72495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid repeated requests to allocate WC pages Applications can request multiple WC pages for the same ucontext. As of now, only 1 WC page per ucontext is supported. Add a lock to avoid concurrent access and a check to fail repeated requests. Also, if the mmap entry insert fails for the WC, free the Doorbell page index mapped for the WC page.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72501", "url": "https://ubuntu.com/security/CVE-2026-72501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Initialize dpi variable to zero dpi is initialized only for BNXT_RE_ALLOC_WC_PAGE, but copied for all the cases. So initialize the dpi to 0.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72278", "url": "https://ubuntu.com/security/CVE-2026-72278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Re-translate VNCR before injecting abort KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor updates and MMU faults.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68083", "url": "https://ubuntu.com/security/CVE-2026-68083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix path resolution in ksmbd_vfs_kern_path_create The SMB2 open lookup is rooted at the share with LOOKUP_BENEATH, but the create/mkdir/hardlink sink is not: ksmbd_vfs_kern_path_create() builds an absolute path with convert_to_unix_name() and resolves it from AT_FDCWD via start_creating_path(), so a \"..\" component is walked from the real filesystem root and escapes the export. An authenticated client races a missing path component so the rooted open lookup returns -ENOENT (taking the create branch) while the same component is present (a directory) when the create walk runs; the create then resolves \"..\" out of the share. Root the create walk at the share like the lookup and rename paths already are: resolve the parent with vfs_path_parent_lookup(..., LOOKUP_BENEATH, &share_conf->vfs_path) and create the final component with start_creating_noperm(). convert_to_unix_name() then has no callers and is removed.", "cve_priority": "high", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-68457", "url": "https://ubuntu.com/security/CVE-2026-68457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use opener credentials for FSCTL mutations SET_SPARSE, SET_ZERO_DATA and SET_COMPRESSION operate on an open SMB handle but call VFS xattr, fallocate or fileattr helpers with the current ksmbd worker credentials. Those helpers can revalidate inode permissions, ownership and LSM policy independently of the SMB handle access mask. Run each operation with the credentials captured in the target file when the handle was opened. Keep credential handling local to these single-file FSCTLs rather than applying session credentials to the complete IOCTL handler, which also contains handle-less and multi-handle operations.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-68476", "url": "https://ubuntu.com/security/CVE-2026-68476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72041", "url": "https://ubuntu.com/security/CVE-2026-72041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: espintcp: use sk_msg_free_partial to fix partial send sk_msg_free_partial() ensures consistency of the skmsg at every iteration, without having to manually handle uncharges and offsets. This simplifies the code, and fixes some bugs in skmsg accounting when we don't send the full contents.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72046", "url": "https://ubuntu.com/security/CVE-2026-72046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing.", "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-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21: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-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72137", "url": "https://ubuntu.com/security/CVE-2026-72137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: nat_keepalive: avoid double free on send error nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6 send helper reports an error. That cleanup is only correct before the skb is handed to the output path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the networking stack may already have consumed the skb before returning an error, so freeing it again is unsafe. Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4() and nat_keepalive_send_ipv6(), where the caller still owns the skb, and keep nat_keepalive_send() responsible only for family dispatch and the unsupported-family cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72139", "url": "https://ubuntu.com/security/CVE-2026-72139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: defer md5sig_info kfree past RCU grace period in tcp_connect The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: \tif (needs_md5) { \t\ttcp_ao_destroy_sock(sk, false); \t} else if (needs_ao) { \t\ttcp_clear_md5_list(sk); \t\tkfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); \t} Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with tcp-diag]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72191", "url": "https://ubuntu.com/security/CVE-2026-72191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: validate split-point offset in indx_insert_into_buffer indx_insert_into_buffer() computes used = used1 - to_copy - sp_size; memmove(de_t, Add2Ptr(sp, sp_size), used - le32_to_cpu(hdr1->de_off)); where sp and sp_size come from hdr_find_split(). hdr_find_split() walks entries by le16_to_cpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFS_DE). index_hdr_check(), the on-load gatekeeper, only validates header-level fields (used, total, de_off) and does not walk per-entry sizes. A crafted NTFS image whose leaf INDEX_HDR reports used == total but contains one interior NTFS_DE with size = 0xFFF0 therefore passes validation, descends to indx_insert_into_buffer() through the ntfs_create() -> indx_insert_entry() path, and makes hdr_find_split() return an sp whose sp_size (0xFFF0) greatly exceeds the remaining bytes in the buffer. The u32 subtraction underflows and the memmove count becomes a near-4-GiB value, producing an out-of-bounds kernel write that corrupts adjacent allocations and panics the kernel. Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a single 'touch' inside the mounted directory; crash site resolves to fs/ntfs3/index.c at the memmove. Trigger requires only local mount of an attacker-supplied filesystem image (USB, loopback, or removable media auto-mount). Reject the split whenever the chosen sp plus its declared size already extends past hdr1->used. This is the minimal fix; it preserves the existing hdr_find_split() contract and relies on the same out: cleanup path as the pre-existing error returns. A prior OOB read in the very same indx_insert_into_buffer() memmove was fixed in commit b8c44949044e (\"fs/ntfs3: Fix OOB read in indx_insert_into_buffer\") by tightening hdr_find_e(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdr_find_split(), not hdr_find_e(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72217", "url": "https://ubuntu.com/security/CVE-2026-72217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing xdr_buf_to_bvec() writes a bio_vec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it. rq_bvec, the array passed by nfsd_vfs_write(), is allocated to exactly rq_maxpages entries with no slack. The OOB store can land in adjacent slab memory; the bv_len and bv_offset fields written there are derived from client-supplied RPC payload sizes. Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72220", "url": "https://ubuntu.com/security/CVE-2026-72220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp->rq_procinfo->pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72221", "url": "https://ubuntu.com/security/CVE-2026-72221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: wait for in-flight TLS handshake callback when cancel loses race When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed. The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result. If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue. If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed. Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed to fire because handshake_complete() invokes svc_tcp_handshake_done() unconditionally once it has set HANDSHAKE_F_REQ_COMPLETED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72222", "url": "https://ubuntu.com/security/CVE-2026-72222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: pin svc_xprt across the asynchronous TLS handshake callback svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of(). Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done. The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry. Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all(). [cel: rewrote commit message to describe the actual change]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72277", "url": "https://ubuntu.com/security/CVE-2026-72277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the simpler thing for now and just reject everything that isn't memory.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72279", "url": "https://ubuntu.com/security/CVE-2026-72279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR KVM currently maps the L1 VNCR into the host stage-1 by relying entirely on the permissions of the guest stage-1. At the same time, it is entirely possible that the backing PFN is read-only (e.g. RO memslot), meaning that the L1 VNCR should use at most a read-only mapping. Cache the writability of the PFN in the VNCR TLB and use it to constrain the resulting fixmap permissions. Promote VNCR permission faults to an SEA in the case where the guest attempts to write to a read-only endpoint. Conveniently, this also plugs a page leak found by Sashiko [*] resulting from the early return for a read-only PFN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72288", "url": "https://ubuntu.com/security/CVE-2026-72288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling Hyunwoo Kim reports some really bad races should the following situation occur: - LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C If the last two race nicely enough, vgic_prune_ap_list() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows. The fix is two-fold: - Before dropping the irq and ap_list locks, take a reference on the irq - Do not try to handle migration of the pending bit: there is no expectation that this state is retained, as per the architecture With that, we're sure that the interrupt is still around, and we safely remove it from the AP list as it has no target at this stage (unless another interrupt fires, but that's another story).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "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-72317", "url": "https://ubuntu.com/security/CVE-2026-72317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: pin upper rpc_clnt across the TLS connect_worker The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt. The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported. Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one. The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72318", "url": "https://ubuntu.com/security/CVE-2026-72318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate DFS referral string offsets parse_dfs_referrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server. Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative max_len is then passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds. Validate each string offset before deriving the string pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72320", "url": "https://ubuntu.com/security/CVE-2026-72320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_lookup: fix catchall element handling with inverted lookups nft_lookup_eval() decides whether a lookup matched (`found`) from the direct set lookup and priv->invert before falling back to the catchall element used by interval sets (e.g. nft_set_rbtree) for the open-ended default range. Since `found` is never recomputed after `ext` is replaced by the catchall lookup, inverted lookups (NFT_LOOKUP_F_INV, \"!= @set\") can wrongly match or wrongly skip the catchall element, producing the wrong verdict. Fold the catchall lookup into `ext` before computing `found`, matching the order already used by nft_objref_map_eval().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72323", "url": "https://ubuntu.com/security/CVE-2026-72323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer. A similar issue in IPv6 MLD is fixed in a subsequent patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72366", "url": "https://ubuntu.com/security/CVE-2026-72366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_create_write_req() to handle async cache object creation netfs_create_write_req() will skip caching if the fscache cookie is disabled, but this is a problem because async cache object creation might not have got far enough yet that has been enabled - thereby causing the call to fscache_begin_write_operation() to be skipped. Fix this by removing the checks on the cookie and delegating this to fscache_begin_write_operation().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72381", "url": "https://ubuntu.com/security/CVE-2026-72381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of fp->owner.name in durable handle owner check Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same persistent_id race the fp->owner.name compare-read in ksmbd_vfs_compare_durable_owner() against the kfree() in ksmbd_reopen_durable_fd()'s reopen-success path. fp->owner.name is a standalone kstrdup() buffer whose lifetime is independent of the fp refcount, and the two sites share no lock: the compare reads the buffer while the reopen frees it, so the strcmp() can dereference freed memory. Commit 7ce4fc40018d (\"ksmbd: fix durable reconnect double-bind race in ksmbd_reopen_durable_fd\") made the fp->conn claim atomic under global_ft.lock (closing the owner.name double-free and the ksmbd_file write-UAF), but the compare-read versus reopen-free pair was left unserialized. BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80 Read of size 1 by task kworker strcmp ksmbd_vfs_compare_durable_owner smb2_check_durable_oplock smb2_open Freed by task kworker: kfree ksmbd_reopen_durable_fd smb2_open Allocated by task kworker: kstrdup session_fd_check smb2_session_logoff The buggy address belongs to the cache kmalloc-8 Serialize both sides of the race with fp->f_lock. The global durable file-table lock still protects the durable reconnect claim, but fp->owner.name is per-open state and does not need to block unrelated durable table lookups or reconnects. The teardown is left at its existing location after the reopen-success point so that an __open_id() rollback still retains owner.name for a later legitimate reconnect to verify.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72393", "url": "https://ubuntu.com/security/CVE-2026-72393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: don't cache shinfo across skb realloc fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb including the shared info. We can't use the pointer calculated before the call. BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0 Read of size 4 at addr ff110000262edd98 by task swapper/5/0 Call Trace: fbnic_tx_lso.isra.0+0x668/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 Allocated by task 8653: __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xcc/0x6c0 sock_alloc_send_pskb+0x327/0x3f0 __ip_append_data+0x188b/0x47a0 ip_make_skb+0x24a/0x300 udp_sendmsg+0x14d2/0x21e0 Freed by task 0: kfree+0x123/0x5a0 pskb_expand_head+0x36c/0xfa0 fbnic_tx_lso.isra.0+0x500/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 sch_direct_xmit+0x25b/0x1100 The buggy address belongs to the object at ff110000262edc40 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 344 bytes inside of freed 640-byte region [ff110000262edc40, ff110000262ede", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72398", "url": "https://ubuntu.com/security/CVE-2026-72398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: add INIT verification after cookie unpacking In SCTP handshake, the INIT chunk is initially processed by the server and embedded into the cookie carried in INIT-ACK. The client then returns this cookie via COOKIE-ECHO, where the server unpacks it and reconstructs the original INIT chunk. When cookie authentication is enabled, the cookie contents are protected against tampering, so reusing the unpacked INIT without re-verification is safe. However, when cookie authentication is disabled, the reconstructed INIT can no longer be trusted. In this case, the INIT must be explicitly validated after unpacking to avoid processing potentially tampered data. Add sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO processing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook()) when cookie_auth_enable is disabled. On failure, the new association is freed and the packet is discarded. Also tighten cookie validation in sctp_unpack_cookie() by verifying the embedded chunk type is SCTP_CID_INIT before treating it as an INIT chunk. Finally, update sctp_verify_init() to validate parameter bounds using the actual embedded INIT length instead of chunk->chunk_end, since the INIT stored in COOKIE-ECHO may not span the entire chunk buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72399", "url": "https://ubuntu.com/security/CVE-2026-72399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: check the number of BDs needed for xdp_frame The size of xdp_redirect_arr array is ENETC_MAX_SKB_FRAGS. However, the number of fragments contained in xdp_frame may be greater than or equal to ENETC_MAX_SKB_FRAGS, which will cause the access to xdp_redirect_arr to be out of bounds.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72429", "url": "https://ubuntu.com/security/CVE-2026-72429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix type confusion of dst_entry IOAM uses a dummy dst_entry(null_dst) to mark that the destination should not be changed after the transformation. This dst is stored in the IOAM lwt state and may be passed to dst_cache_set_ip6(). However, the IPv6 dst cache path eventually calls rt6_get_cookie(), which treats the dst_entry as part of a struct rt6_info. Since the null_dst was embedded directly as a struct dst_entry in struct ioam6_lwt, this resulted in an invalid cast and rt6_get_cookie() reading fields from the wrong object. In practice, the wrong cookie is not used while dst->obsolete is zero, but rt6_get_cookie() may also access per-cpu value when rt->sernum is zero. In this case, rt->sernum aliases ioam6_lwt::cache::reset_ts, which can become zero, making this a potential invalid pointer access. Fix this by embedding a full struct rt6_info for the dummy IPv6 route and passing its dst member to the dst APIs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72436", "url": "https://ubuntu.com/security/CVE-2026-72436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash types Sashiko pointed out that there are a few lockless RCU readers using test_bit() which is a relaxed atomic operation and provides no memory barrier guarantees. Use test_bit_acquire() instead where the operation may run parallel with add/del/gc, i.e. is not one from the next cases - protected by region lock - in a set destroy phase - in a new/temporary set creation phase", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72451", "url": "https://ubuntu.com/security/CVE-2026-72451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix xfrm state cache insertion race The xfrm input state cache insertion code checks the validity of the state before acquiring the global xfrm_state_lock. Thus it's possible for someone else to kill the state after it passed the validity check, and then the insertion will add the dead state to the cache. Fix this by moving the validity check inside the lock. This entire function is called on the input path, where BH must be off (e.g., the caller of this function xfrm_input acquires its spinlocks without disabling BH). So there is no need to disable BH here or take the RCU read lock. Remove both and replace them with an assertion that trips if BH is accidentally enabled on some future calling path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72472", "url": "https://ubuntu.com/security/CVE-2026-72472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: use nfsi->rwsem to protect traversal of the file lock list Lingfeng identified a bug and suggested two solutions, but both appear to have issues. Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case. Furthermore, after commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk. Regarding the bug fixed by commit c69899a17ca4 (\"NFSv4: Update of VFS byte range lock must be atomic with the stateid update\"), it has been resolved after commit 0460253913e5 (\"NFSv4: nfs4_do_open() is incorrectly triggering state recovery\") because all slots are drained before calling nfs4_do_reclaim, which prevents concurrent stateid changes along this path. Also, nfs_delegation_claim_locks does not cause this concurrency either since when _nfs4_proc_setlk is called with NFS_DELEGATED_STATE, no RPC is sent, so nfs4_lock_done is not called. Therefore, nfs4_lock_delegation_recall from nfs_delegation_claim_locks is the first time the stateid is set.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72473", "url": "https://ubuntu.com/security/CVE-2026-72473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decouple req recycling from RPC completion rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer. Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off. The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry. Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied. Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected. Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released. The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74310", "url": "https://ubuntu.com/security/CVE-2026-74310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/net: complete zerocopy ubufs only once vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74345", "url": "https://ubuntu.com/security/CVE-2026-74345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix endpoint/socket association handling Disassociating a socket from an endpoint via siw_socket_disassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within. This fixes a: BUG: KASAN: slab-use-after-free in siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1053 drivers/infiniband/sw/siw/siw_cm.c:1075) which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74361", "url": "https://ubuntu.com/security/CVE-2026-74361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: fix FDP fdpcidx bounds check The fdpcidx bounds check sets n = NUMFDPC + 1 but used > instead of >=, incorrectly accepting fdp_idx when it equals n (i.e. NUMFDPC + 1).", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74401", "url": "https://ubuntu.com/security/CVE-2026-74401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: fix add msg handle in send_queue ordered In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as \"before(mh->seq, seq)\" will stop to check for older sequence numbers that are ordered in the tail of \"node->send_queue\". The side effects of not having it correct ordered regarding \"before(mh->seq, seq)\" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74406", "url": "https://ubuntu.com/security/CVE-2026-74406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74428", "url": "https://ubuntu.com/security/CVE-2026-74428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix double unlock in rxrpc_recvmsg() Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74433", "url": "https://ubuntu.com/security/CVE-2026-74433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix UAF in rxgk_issue_challenge() Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74434", "url": "https://ubuntu.com/security/CVE-2026-74434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Don't move a peeked OOB message onto the pending queue rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so only unlink it from recvmsg_oobq and then move it onto pending_oobq or free it when the message is actually consumed.", "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-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-74439", "url": "https://ubuntu.com/security/CVE-2026-74439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clear Present bit before tearing down scalable-mode context entry device_pasid_table_teardown() zeroes the 128-bit scalable-mode context entry with context_clear_entry() while the Present bit is still set. This creates a window where the hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behavior or spurious faults. The context-cache invalidation is issued only after the entry has been zeroed, and intel_pasid_free_table() then frees the PASID directory pages, so the IOMMU can keep walking a stale Present=1 entry that points at freed memory. While x86 provides strong write ordering, the compiler may reorder the two 64-bit writes to the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Commit c1e4f1dccbe9d (\"iommu/vt-d: Clear Present bit before tearing down context entry\") fixed this exact pattern in domain_context_clear_one() and the copied-context path, but device_pasid_table_teardown() was not converted. Align it with the \"Guidance to Software for Invalidations\" in the VT-d spec, Section 6.5.3.3, using the same ownership handshake as the sibling fix: clear only the Present bit, flush it to the IOMMU, perform the context-cache invalidation, and only then zero the rest of the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" } ], "log": [ "", " * noble/linux-riscv-7.0: 7.0.0-38.38.1~24.04.1 -proposed tracker (LP: #2165483)", "", " [ Ubuntu-riscv: 7.0.0-38.38.1 ]", "", " * resolute/linux-riscv: 7.0.0-38.38.1 -proposed tracker (LP: #2165484)", " * resolute: llvm-21-dev build-depends breaks cross-builds (LP: #2165407)", " - [Packaging] Fix cross-builds", " * Zfhmin/Zvfhmin not reported when Zfh/Zvfh are present (LP: #2166547)", " - riscv: report Zfhmin/Zvfhmin when Zfh/Zvfh are present", " [ Ubuntu: 7.0.0-38.38 ]", " * resolute/linux: 7.0.0-38.38 -proposed tracker (LP: #2166443)", " * linux: dtbs_install fails on Resolute builders due to uutils install(1)", " EEXIST race under parallel make (LP: #2166356)", " - SAUCE: [Packaging] Serialise dtbs_install to work around uutils", " install(1) race", " * #510/p sleepable raw tracepoint reject from test_verifier in ubuntu_bpf", " failed with resolute (7.0.0-33.33) generic amd64 (LP: #2165872)", " - SAUCE: Revert \"bpf: Verifier support for sleepable tracepoint programs\"", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189)", " - 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", " - seqlock: Allow UBSAN_ALIGNMENT to fail optimizing", " - KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN", " - crypto: tegra - Don't touch bo refcount in host1x bo pin/unpin", " - xprtrdma: Clear receive-side ownership pointers on release", " - Input: ims-pcu - fix logic error in packet reset", " - fuse: fix writeback array overflow when max_pages is one", " - arm64: tegra: Remove fallback compatible for GPCDMA", " - arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234", " - xfrm: propagate -EINPROGRESS from validate_xmit_xfrm()", " - mtd: mtdswap: remove debugfs stats file on teardown", " - mtd: nand: mtk-ecc: stop on ECC idle timeouts", " - btrfs: fallback to transaction csum tree on a commit root csum miss", " - RDMA/cma: Fix hardware address comparison length in netevent callback", " - RDMA/irdma: Remove redundant legacy_mode checks", " - RDMA/erdma: initialize ret for empty receive WR lists", " - RDMA/mana_ib: initialize err for empty send 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: cfg80211: derive S1G beacon TSF from S1G fields", " - wifi: nl80211: validate nested MBSSID IE blobs", " - wifi: nl80211: constrain MBSSID TX link ID range", " - wifi: cfg80211: validate PMSR measurement type data", " - wifi: cfg80211: reject unsupported PMSR FTM location requests", " - wifi: mac80211: avoid non-S1G AID fallback for S1G assoc", " - ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on", " start/stop", " - ASoC: amd: ps: disable MSI on resume in ACP PCI driver", " - ASoC: amd: ps: fix wrong ACP version string in pci_request_regions()", " - ASoC: amd: ps: replace bitwise OR with logical OR in IRQ return check", " - 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", " - cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq", " - udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()", " - ata: sata_dwc_460ex: use platform_get_irq()", " - ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending", " interrupts", " - accel/ivpu: Fix wrong register read in LNL failure diagnostics", " - ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC", " - drm/i915/gt: use correct selftest config symbol", " - powerpc/85xx: Add fsl,ifc to common device ids", " - powerpc/time: Prepare to stop elapsing in dynticks-idle", " - powerpc/vtime: Initialize starttime at boot for native accounting", " - drm/panthor: Check debugfs GEM lock initialization", " - riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()", " - can: j1939: fix lockless local-destination check", " - drm/xe/wopcm: fix WOPCM size for LNL+", " - drm/i915/wm: clear the plane ddb_y entries on plane disable", " - 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: gadget: fsl-udc: fix dev_printk() device", " - 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", " - SAUCE: Revert \"usb: typec: ucsi: Detect and skip duplicate altmodes from", " buggy firmware\"", " - usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware", " - wifi: mwifiex: fix freeze for 60 seconds caused by request_firmware", " - RISC-V: KVM: Serialize virtual interrupt pending state updates", " - Revert \"drm/amd/display: Add missing kdoc for ALLM parameters\"", " - usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits", " - selftests/bpf: Adjust verifier_map_ptr for the map's excl field", " - selftests/bpf: Keep verifier_map_ptr exercising ops pointer access", " - 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", " - btrfs: fix u32 to s64 type conversion in dirty_metadata_bytes accounting", " - ASoC: sun4i-codec: Set quirks.playback_only for H616 codec", " - 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: fix pointer arithmetic in iwl_add_mcc_to_tas_block_list", " - wifi: iwlwifi: validate payload length in iwl_pnvm_complete_fn", " - wifi: iwlwifi: mvm: fix read in wake packet notification handler", " - usb: atm: ueagle-atm: reject descriptors that confuse probe and", " disconnect", " - drivers/virt: pkvm: Fix end calculation in mmio_guard_ioremap_hook()", " - 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", " - selftests/net: ovpn: fix getaddrinfo memory leak in ovpn_parse_remote()", " - ovpn: use monotonic clock for peer keepalive timeouts", " - regulator: mt6358: use regmap helper to read fixed LDO calibration", " - net: phy: marvell: fix return code", " - netlink: specs: rt-link: convert bridge port flag attributes to u8", " - gtp: parse extension headers before reading inner protocol", " - vhost-net: fix TX stall when vhost owns virtio-net header", " - wifi: mac80211: recalculate TIM when a station enters power save", " - pds_core: reject component parameter in legacy firmware update", " - arm64: Correct value returned by ESR_ELx_FSC_ADDRSZ_nL()", " - amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN", " - soreuseport: Clear sk_reuseport_cb before failure in sk_clone().", " - net: Call net_enable_timestamp() before failure in sk_clone().", " - 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", " - selftests: af_unix: add USER_NS config", " - selftests: openvswitch: add config file", " - selftests: ovpn: add IPV6 and VETH configs", " - selftests: ovpn: increase timeout", " - selftests: drv-net: increase timeout", " - ppp: don't store tx skb in the fastpath", " - ppp: annotate concurrent dev->stats accesses", " - ovl: fix trusted xattr escape prefix matching", " - drm/panel: s6e3ha8: fix unmet dependency on DRM_DISPLAY_HELPER", " - 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", " - drm/xe/i2c: Allow per domain unique id", " - iomap: correct the range of a partial dirty clear", " - drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem", " - net: stmmac: xgmac: fix l4 filter port overwrite on register update", " - 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: annotate data races in ppp_generic", " - hinic: remove unused ethtool RSS user configuration buffers", " - raw: annotate lockless match fields in raw_v4_match()", " - 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", " - octeontx2-pf: tc: fix egress ratelimiting", " - net: ipv6: fix dif and sdif mismatch in raw6_icmp_error", " - ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV", " - ice: fix LAG recipe to profile association", " - ipv6: Change allocation flags to match rcu_read_lock section", " requirements", " - ptp: netc: explicitly clear TMR_OFF during initialization", " - mctp: check register_netdevice_notifier() error in mctp_device_init()", " - net: airoha: fix ETS channel derivation in airoha_tc_setup_qdisc_ets()", " - drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay", " - drm: renesas: rzg2l_mipi_dsi: Move rzg2l_mipi_dsi_set_display_timing()", " - drm/tidss: Fix missing drm_bridge_add() call", " - 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/sysfb: Do not page-align visible size of the framebuffer", " - drm/sysfb: Avoid truncating maximum stride", " - drm/amdgpu/gfx9: Fix Ring and IB test fail after mode2", " - drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT", " - drm/sysfb: Return errno code from drm_sysfb_get_visible_size()", " - drm/displayid: fix Tiled Display Topology ID size", " - drm/nouveau/acr: fix missing nvkm_done() in error path of", " nvkm_acr_oneinit()", " - drm/radeon: fix r100_copy_blit for large BOs", " - drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked binds", " - drm/amdkfd: Use kvcalloc to allocate arrays", " - drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips", " - drm/i915/hdcp: require monotonically increasing seq_num_v", " - drm/amd/amdgpu: disable ASPM on VI if pcie dpm is disabled", " - drm/amd/pm: fix smu14 power limit range calculation", " - drm/gfx10: Program DB_RING_CONTROL", " - drm/virtio: Don't detach GEM from a non-created context", " - drm/panthor: return error on truncated firmware", " - drm/amdgpu: Fix VFCT bus number matching with soft filter", " - drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)", " - drm/amd/display: consolidate DCN vblank/flip handling onto", " vupdate_no_lock", " - drm/amd/display: Force PWM backlight on Lenovo Legion 5 15ARH05", " - drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge", " - drm/amd/display: Fix flip-done timeouts on mode1 reset", " - drm/amd/display: Fix missing DCE check in", " dm_gpureset_toggle_interrupts()", " - drm/v3d: Reach the GMP through the hub registers on V3D 7.x", " - 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: imx219: Fix maximum frame length in lines", " - media: iris: Fix use IRQF_NO_AUTOEN when requesting the IRQ", " - media: marvell-cam: fix missing pci_disable_device() on remove", " - media: nuvoton: npcm-video: fix error handling in npcm_video_init()", " - 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: qcom: camss: Fix RDI streaming for CSID 680", " - media: qcom: camss: Fix RDI streaming for CSID GEN2", " - media: qcom: camss: Fix RDI streaming for CSID GEN3", " - media: rzg2l-cru: Skip ICnMC configuration when ICnSVC is used", " - media: synopsys: hdmirx: Fix HPD lane hold time", " - 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: v4l2-subdev: Fail {enable,disable}_streams and s_streaming nicely", " - media: vb2: use ssize_t for vb2_read/vb2_write", " - media: verisilicon: Export only needed pixels formats", " - media: vidtv: fix reference leak on failed device registration", " - media: vimc: fix reference leak on failed device registration", " - media: vpif_capture: fix OF node reference imbalance", " - ALSA: hda/realtek: Fix speakers on Lunnen Ground 14", " - ALSA: hda: codecs: hdmi: disable keep-alive before audio format change", " - wifi: brcmfmac: set F2 blocksize to 256 for BCM43752", " - wifi: ath11k: fix refcount leak in ath11k_ahb_fw_resources_init()", " - staging: rtl8723bs: fix inverted HT40 secondary channel offset", " - platform/loongarch: laptop: Explicitly reset bl_powered state when", " suspend", " - rust_binder: only print failure if error has source", " - rust: time: fix as_micros_ceil() to round correctly for negative Delta", " - rust: allow `clippy::unwrap_or_default` globally", " - objtool/rust: add one more `noreturn` Rust function for Rust 1.99.0", " - LoongArch: Fix address space mismatch in kexec command line lookup", " - LoongArch: Fix oops during single-step debugging", " - LoongArch: Move jump_label_init() before parse_early_param()", " - LoongArch: Retrieve CPU package ID from PPTT when available", " - x86/boot/compressed: Disable jump tables", " - uio_hv_generic: Bind to FCopy device by default", " - serial: sc16is7xx: implement gpio get_direction() callback", " - selftests: ntsync: correct CONFIG_NTSYNC name", " - tracing: Fix context switch counter truncation", " - 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()", " - mptcp: decrement subflows counter on failed passive join", " - mptcp: only set DATA_FIN when a mapping is present", " - mm/kmemleak: fix checksum computation for per-cpu objects", " - mm/huge_memory: set PG_has_hwpoisoned only after new folio head is", " established", " - ceph: fix refcount leak in ceph_readdir()", " - ceph: fix writeback_count leak in write_folio_nounlock()", " - ASoC: fsl: imx-card: Skip sysclk reset for active DAIs in shutdown", " - ASoC: fsl_sai: Fix spurious BCLK on resume by clearing BYP", " - io_uring/rw: fix missing ERESTARTSYS conversion in read paths", " - iommu/vt-d: Disallow SVA if page walk is not coherent", " - net: stmmac: intel: skip SerDes reconfig when rate is unchanged", " - net: pcs: xpcs: fix SGMII state reading", " - proc: Fix broken error paths for namespace links", " - s390/ptff: Export ptff_function_mask[]", " - smb: client: handle STATUS_STOPPED_ON_SYMLINK responses without a", " symlink target", " - ice: use READ_ONCE() to access cached PHC time", " - ovpn: hold peer before scheduling keepalive work", " - vsock/virtio: collapse receive queue under memory pressure", " - watchdog: s32g_wdt: remove incorrect options in watchdog_info struct", " - drm/amd/pm: fix amdgpu_pm_info power display units", " - drm/amd/pm: make pp_features read-only when scpm is enabled", " - drm/amdgpu/jpeg: fix jpeg_v4_0_3_is_idle detection", " - drm/amdgpu/jpeg: fix jpeg_v5_0_1_is_idle detection", " - drm/amdgpu/soc24: reset dGPU if suspend got aborted", " - drm/amdgpu: fix resource leak on ACP reset timeout", " - drm/amd/pm: fix smu13 power limit range calculation", " - drm/amdgpu: fix check in amdgpu_hmm_invalidate_gfx", " - drm/xe/uapi: Reject coh_none PAT index for CPU_ADDR_MIRROR", " - net: qrtr: ns: Raise node count limit to 512", " - drm/amd/display: Fix DTB DTO updates breaking live pixel rate sources", " - audit: widen ino fields to u64", " - audit: use 'unsigned int' instead of 'unsigned'", " - xfs: don't replace the wrong part of the cow fork", " - netfilter: nf_tables: remove register tracking infrastructure", " - drm: drop lib from header search path.", " - SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlists", " - SUNRPC: Return an error from xdr_buf_to_bvec() on overflow", " - SAUCE: Revert \"mm/sparse-vmemmap: fix vmemmap accounting underflow\"", " - mm/sparse-vmemmap: fix vmemmap accounting underflow", " - mmc: vub300: rename probe error labels", " - net: mana: Optimize irq affinity for low vcpu configs", " - bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c", " - bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()", " - pmdomain: imx93-blk-ctrl: convert to devm_* only", " - rust: allow `suspicious_runtime_symbol_definitions` lint for Rust >=", " 1.98", " - rust: device: avoid trailing ; in printing macros", " - sched_ext: Skip ops.set_weight() for disabled tasks", " - sched_ext: Annotate ksyncs with __rcu in alloc/free_kick_syncs()", " - reset: spacemit: k3: fix USB2 ahb reset", " - wifi: cfg80211: reject empty PMSR peer lists", " - ASoC: amd: acp: Fix linker error with SDCA quirks", " - [Config] Adjust config SND_SOC_ACPI_AMD_SDCA_QUIRKS", " - sched_ext: Enable tick for finite slices on nohz_full", " - Bluetooth: mgmt: Translate HCI reason in Device Disconnected event", " - riscv: Gate FUNCTION_ALIGNMENT_4B on DYNAMIC_FTRACE", " - spi: cadence-quadspi: Fix indirect write timeout when DMA read mode is", " enabled", " - drm/xe: Assign queue name in time for drm_sched_init", " - drm/xe: add WQ_PERCPU to alloc_workqueue users", " - selftests: netconsole: only restore MAC when it changed on resume", " - wifi: ath10k: fix skb leak on incomplete msdu during rx pop", " - wifi: ath12k: Fix low MLO RX throughput on WCN7850", " - iommu/amd: Fix nested domain leak", " - arm_mpam: Fix software reset values of MPAMCFG_PRI", " - arm_mpam: Fix MPAMCFG_MBW_PBM register setting", " - hwmon: Drop unused i2c driver_data", " - hwmon: Use named initializers for arrays of i2c_device_data", " - hwmon: (pmbus/max34440): add support adpm12250", " - hwmon: (pmbus/max34440) block unsupported VIN and IIN limit registers", " - drm/i915/backlight: Remove DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check for", " DPCD backlight", " - selftests/net: Fix tun IPv6 test addresses to avoid 6to4 range", " - geneve: fix hint header definition wrt endianness", " - geneve: ensure the skb is writable before fixing its headers", " - accel: ethosu: Handle U85 internal chaining buffer", " - selftests: drv-net: convert so_txtime to drv-net", " - cifs: prevent readdir from changing file size due to stale directory", " metadata", " - wifi: mt76: fix airoha_npu dependency tracking", " - [Config] Fix config dependencies for MT76_NPU", " - drm/panel: ilitek-ili9882t: fix unmet dependency for", " DRM_PANEL_ILITEK_ILI9882T", " - iomap: fix incorrect did_zero setting in iomap_zero_iter()", " - mpls: Set rt->rt_nhn just before returning from mpls_nh_build_multi().", " - LoongArch: BPF: Zero-extend signed ALU32 div/mod results", " - bnge/bng_re: fix ring ID widths", " - pidfs: make pidfs_ino_lock static", " - LoongArch: BPF: Fix memory leak in bpf_jit_free()", " - drm/exynos: fbdev: Remove offset into screen_buffer", " - drm/tegra: fbdev: Remove offset into framebuffer memory", " - drm/i915/cdclk: Fix up CDCLK_FREQ_DECIMAL without a full PLL re-enable", " - drm/amd/pm: re-enable MC access after PrepareMp1ForUnload on SMU V15", " APUs", " - bitmap: add test_zero_nbits()", " - drm/xe: Add compact-PT and addr mask handling for page reclaim", " - drm/amd/display: Restore periodic detection for DCN35", " - drm/amdgpu: Respect placement requirements in amdgpu_gtt_mgr functions", " - drm/amdkfd: Use exclusive bounds for SVM split alignment checks", " - drm/i915/mtl+: Enable PPS before PLL", " - drm/xe/oa: Fix offset alignment for MERT WHITELIST_OA_MERT_MMIO_TRG", " - drm/xe/nvm: fix writable override for CRI", " - drm/amdgpu: Check for multiplication overflow in checkpoint stack size", " - drm/amdkfd: Guard m->cp_hqd_eop_control setting by", " q->eop_ring_buffer_size", " - drm/amdkfd: free MQD managers on DQM init failures", " - drm/amd/display: set MSA MISC1 bit 6 when using VSC SDP for DCE 11.x", " - drm/amdgpu: add the doorbell index input for suspending userq", " - drm/amdgpu: remove deadlocks from amdgpu_userq_pre_reset", " - drm/amd: Create a device link between APU display and XHCI devices", " - drm/pagemap: Clear driver-provided PFNs from migration PFN array", " - mm: add gpu active/reclaim per-node stat counters (v2)", " - drm/ttm: use gpu mm stats to track gpu memory allocations. (v4)", " - drm/ttm: Fix GPU MM stats during pool shrinking", " - drm/ttm/pool: back up at native page order", " - drm/gpusvm: Zero HMM PFNs before scanning ranges", " - media: mali-c55: Add missing of_reserved_mem_device_release()", " - media: mali-c55: Disable pm_runtime on probe error", " - media: mali-c55: Power-off the peripheral in remove()", " - media: qcom: camss: Fix RDI streaming for CSID 340", " - media: rzv2h-ivc: Wait for frame end in stop_streaming", " - media: ti: vpe: Fix fwnode_handle leak in vip_probe_complete()", " - media: ti: vpe: Fix the error code of devm_request_irq()", " - media: uapi: rkisp: Correct name version enum", " - wifi: mt76: restrict NPU/PPE active checks to MMIO devices", " - LoongArch: Fix build errors due to wrong instructions for 32BIT", " - LoongArch: Increase TASK_STRUCT_OFFSET up to 2040 for 32BIT", " - firmware: stratix10-svc: fix teardown order in remove to prevent race", " - firmware: stratix10-svc: handle NO_RESPONSE in async poll", " - tracing: perf: Fix stale head for perf syscall tracing", " - 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\"", " - selftests: mptcp: userspace_pm: fix undefined variable port", " - m68k: avoid -Wunused-but-set-parameter in clear_user_page()", " - mm/memory-failure: trace: change memory_failure_event to ras subsystem", " - mm/slub: fix lost local objects when bulk remote free batch fills", " - mm/slab: fix a memory leak due to bootstrapping sheaves twice", " - drm/amdgpu: rework userq fence driver alloc/destroy", " - drm/amdgpu: rework userq fence signal processing", " - drm/amdgpu/gfx11: fix EOP interrupt routing for KQ and userq", " - drm/amdgpu/gfx12: fix EOP interrupt routing for KQ and userq", " - drm/amdgpu/mes11: set doorbell offset for suspending userq", " - selftests: drv-net: add missing kconfig for psp.py", " - mm/sparse-vmemmap: pass @pgmap argument to memory deactivation paths", " - mm/sparse-vmemmap: fix DAX vmemmap accounting with optimization", " - selftests: drv-net: cope with slow env in so_txtime.py test", " - selftests: drv-net: so_txtime: relax variance bounds", " - cifs: fix time_last_write stamp placement in setattr/truncate paths", " - cifs: consolidate time_last_write stamp into _cifsFileInfo_put()", " - Upstream stable to v6.18.41, v6.18.42, v6.18.43, v7.1.6, v7.1.7", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68480", " - x86/bugs: Make Safe-RET robust against interrupt injection", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68105", " - drm/amdgpu: Fix kernel panic during driver load failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68109", " - drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68114", " - drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68431", " - ksmbd: validate minimum PDU size for transform requests", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68138", " - net/sched: serialize qdisc_rtab_list against concurrent get/put", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68082", " - libceph: fix two unsafe bare decodes in decode_lockers()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68159", " - libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68163", " - mm/page_vma_mapped: fix device-private PMD handling", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68166", " - userfaultfd: prevent registration of special VMAs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68170", " - mptcp: fix stale skb->sk reference on subflow close", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68177", " - tracing: Delay module ref count for \"enable_event\" trigger", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68191", " - wifi: ath12k: fix NULL pointer dereference in rhash table destroy", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64586", " - wifi: brcmfmac: drain bus_reset work on device removal", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68208", " - media: ti: vpe: Fix the error code of devm_kzalloc() in", " vip_probe_slice()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68224", " - media: mali-c55: Fix possible ERR_PTR in enable_streams", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68237", " - drm/amdgpu/userq: fix indefinite fence wait during GPU reset", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68240", " - drm/gpusvm: publish dpagemap early to avoid device mapping leak on error", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68242", " - drm/i915/gt: Fix NULL deref on sched_engine alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68254", " - drm/i915/vrr: require valid min/max vfreq for VRR", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68436", " - drm/amd/display: use kvzalloc to allocate struct dc", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68447", " - drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68264", " - drm/xe/pt: Reset current_op in xe_pt_update_ops_init()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68265", " - drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68267", " - drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68273", " - drm/amdgpu: Fix context pstate override handling", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68274", " - drm/xe/guc: Fix buffer overflow in steered register list allocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68283", " - tracing: Fix use-after-free freeing trigger private data", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68286", " - drop_monitor: perform u64_stats updates under IRQ-disabled section", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68287", " - drop_monitor: fix size calculations for 64-bit attributes", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68288", " - net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68289", " - tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68291", " - idpf: fix max_vport related crash on allocation error during init", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68303", " - drm/vc4: hvs/v3d: Fix null dereference in unbind", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68312", " - cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain", " paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68316", " - accel: ethosu: Fix element size accounting for cmd stream validation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68322", " - rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68440", " - net: txgbe: fix heap overflow when reading module EEPROM", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68323", " - tipc: serialize udp bearer replicast list updates", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68441", " - net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68337", " - bpf: Reject redirect helpers without a bpf_net_context", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68345", " - arm_mpam: guard MBWU state before adding it to garbage", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68347", " - iommu/amd: Fix IRQ unsafe locking in gdom allocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68375", " - bnxt_en: Handle partially initialized auxiliary devices", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68382", " - drm/xe/guc: Hold device ref until queue teardown completes", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68383", " - drm/xe/guc: Keep scheduler timeline name alive", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68390", " - Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68399", " - bpf: Fix UAF in sock clone early bailouts", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68404", " - wifi: cfg80211: use wiphy work for socket owner autodisconnect", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64581", " - xfrm: fix sk_dst_cache double-free in xfrm_user_policy()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68093", " - KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision", " after hotplug", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68367", " - usb: gadget: f_tcm: synchronize delayed set_alt with teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68164", " - mm/damon/core: disallow overlapping input ranges for damon_set_regions()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68165", " - mm/damon/core: validate ranges in damon_set_regions()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68095", " - fuse-uring: fix race between registration and connection abortion", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68096", " - audit: fix recursive locking deadlock in audit_dupe_exe()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68147", " - fscrypt: Avoid dynamic allocation in fscrypt_get_devices()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68097", " - ksmbd: validate ACE size against SID sub-authorities", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68098", " - ksmbd: bound DACL dedup walk to copied ACEs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68099", " - ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68100", " - ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68173", " - ublk: wait on ublk_dev_ready() instead of ub->completion", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68104", " - drm/amdgpu: invoke pm_genpd_remove() before freeing genpd", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68106", " - drm/amdgpu: fix division by zero with invalid uvd dimensions", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68429", " - drm/dp_mst: Handle torn-down topology gracefully in", " drm_dp_mst_topology_queue_probe()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68107", " - drm/amdgpu/vcn4: avoid rereading IB param length", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68108", " - drm/amdgpu/vce: fix integer overflow in image size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68110", " - drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68111", " - drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68112", " - drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68430", " - drm/amdgpu/gfx8: drop unecessary BUG_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68113", " - drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68246", " - drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68115", " - drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68116", " - vxlan: mdb: Fix source list corruption on a failed replace", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68117", " - tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68118", " - tcp: challenge ACK for non-exact RST in SYN-RECEIVED", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68119", " - tcp: initialize standalone TCP-AO response padding", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68120", " - rtase: Workaround for TX hang caused by hardware packet parsing", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68121", " - pppoe: reload header pointer after dev_hard_header()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68122", " - ovpn: fix peer refcount leak in TCP error paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68123", " - openvswitch: fix GSO userspace truncation underflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68124", " - mctp: serial: handle zero-length frames to prevent rx buffer overflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68125", " - mac802154: llsec: reject frames shorter than the authentication tag", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68126", " - mac802154: hold an interface reference across the scan worker", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68127", " - ila: reload IPv6 header after pskb_may_pull in checksum adjust", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68128", " - ice: reject out-of-range ptype in ice_parser_profile_init", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68129", " - gve: fix Rx queue stall on alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68130", " - ksmbd: defer destroy_previous_session() until after NTLM authentication", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68131", " - rbd: Reset positive result codes to zero in object map update path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68132", " - super: fix emergency thaw deadlock on frozen block devices", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68133", " - ice: fix PTP Call Trace during PTP release", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68134", " - ptp: ptp_s390: Add missing facility check", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68135", " - net: hip04: fix RX buffer leak on build_skb failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68136", " - net: gro: fix double aggregation of flush-marked skbs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68137", " - net/x25: fix use-after-free in x25_kill_by_neigh()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68139", " - net/mlx5e: Use sender devcom for MPV master-up", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68140", " - net/iucv: fix use-after-free of a severed iucv_path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68141", " - net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68142", " - geneve: require CAP_NET_ADMIN in the device netns for changelink", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68143", " - net: slip: serialize receive against buffer reallocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68432", " - vxlan: require CAP_NET_ADMIN in the device netns for changelink", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68144", " - phonet: pep: fix use-after-free in pep_get_sb()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68145", " - iomap: fix out-of-bounds bitmap_set() with zero-length range", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68146", " - ftrace: Add global mutex to serialize trace_parser access", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68148", " - fscrypt: Add missing superblock check in find_or_insert_direct_key()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68149", " - fs: preserve ACL_DONT_CACHE state in forget_cached_acl()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68150", " - fs/super: fix emergency thaw double-unlock of s_umount", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68151", " - binfmt_elf_fdpic: only honour the first PT_INTERP", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68152", " - amt: fix use-after-free in AMT delayed works", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68153", " - libceph: remove debugfs files before client teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68154", " - libceph: reject zero bucket types in crush_decode", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68155", " - libceph: Reject monmaps advertising zero monitors", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68156", " - libceph: refresh auth->authorizer_buf{,_len} after authorizer update", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68157", " - libceph: guard missing CRUSH type name lookup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68158", " - libceph: Fix multiplication overflow in decode_new_up_state_weight()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68433", " - libceph: bound get_version reply decode to front len", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68160", " - ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68161", " - sctp: close UDP tunnel sockets during netns teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68162", " - sctp: avoid auth_enable sysctl UAF during netns teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64564", " - sctp: don't free the ASCONF's own transport in DEL-IP processing", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68168", " - afs: Fix afs_edit_dir_remove() to get, not find, block 0", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68169", " - mptcp: pm: userspace: fix use-after-free in get_local_id", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68172", " - arm64: make huge_ptep_get handled unaligned addresses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68174", " - tracing: Fix union collision of module and refcnt for dynamic events", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68175", " - tracing: Fix resource leak on mmiotrace trace_pipe close", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68176", " - tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68178", " - misc: nsm: pin the module while the device is open", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68179", " - misc: nsm: only unlock nsm_dev on post-lock error paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68180", " - intel_th: fix MSC output device reference leak", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68181", " - mei: bus: access mei_device under device_lock on cleanup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68434", " - serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR", " platforms", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68182", " - comedi: comedi_parport: deal with premature interrupt", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68183", " - firmware: stratix10-svc: fix memory leaks and list corruption bugs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64563", " - rhashtable: clear stale iter->p on table restart", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68184", " - cdrom: fix stack out-of-bounds read in CDROMVOLCTRL", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68186", " - binfmt_misc: set have_execfd only once the interpreter is opened", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68187", " - exec: fix unsigned loop counter wrap in transfer_args_to_stack()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68188", " - Bluetooth: RFCOMM: Fix session UAF in set_termios", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68189", " - Bluetooth: hci_sync: Protect UUID list traversal", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68190", " - staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68192", " - wifi: brcmfmac: make release_scratchbuffers idempotent", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68193", " - wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68194", " - wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68195", " - wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68196", " - wifi: wilc1000: validate assoc response length before subtracting header", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68197", " - wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-", " oper", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68198", " - wifi: ath6kl: fix use-after-free in aggr_reset_state()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68199", " - wifi: ath6kl: fix OOB access from firmware ADDBA window size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68200", " - ALSA: timer: don't re-enter an instance callback that is still running", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68201", " - ALSA: timer: drain a slave's callback before its master detaches it", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68202", " - ALSA: seq: close a re-opened queue timer in the destructor", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68203", " - media: vivid: fix cleanup bugs in vivid_init()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68204", " - media: vivid: check for vb2_is_busy() when toggling caps", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68205", " - media: v4l2-fwnode: Fix subdev owner overwritten in", " v4l2_async_register_subdev_sensor()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68206", " - media: v4l2-ctrls: validate HEVC active reference counts", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68207", " - media: ti: vpe: unwind v4l2 device registration on probe error", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68209", " - media: sun4i-csi: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68210", " - media: stm32: dcmi: unregister notifier on probe failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68211", " - media: stm32-dcmipp: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68212", " - media: saa7134: Fix a possible memory leak in saa7134_video_init1", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68213", " - media: rtl2832_sdr: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68214", " - media: rtl2832: fix use-after-free in rtl2832_remove()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68215", " - media: radio-si476x: Unregister v4l2_device on probe failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68216", " - media: pwc: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68217", " - media: pwc: Drain fill_buf on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68218", " - media: pci: dm1105: Free allocated workqueue", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68219", " - media: nxp: imx8-isi: Fix potential out-of-bounds issues", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68220", " - media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and", " pipe", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68221", " - media: nuvoton: npcm-video: fix memory leaks in probe and remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68222", " - media: msi2500: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68223", " - media: meson: vdec: Fix memory leak in error path of vdec_open", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68225", " - media: i2c: alvium: fix critical pointer access in alvium_ctrl_init", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68226", " - media: cx23885: add ioremap return check and cleanup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68227", " - media: cx231xx: fix devres lifetime", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68228", " - media: chips-media: wave5: Move src_buf Removal to finish_encode", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68229", " - media: cedrus: skip invalid H.264 reference list entries", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68230", " - media: amlogic-c3: Add validations for ae and awb config", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68231", " - media: airspy: Return queued buffers on start_streaming() failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68232", " - drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68445", " - drm/vc4: Prevent shader BO mappings from becoming writable", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68446", " - drm/vmwgfx: Validate vmw_surface_metadata::array_size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68233", " - drm/vc4: Shut down BO cache timer before teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68234", " - drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68235", " - drm/amd/display: dce100: skip non-DP stream encoders for DP MST", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68236", " - drm/amd/display: set new_stream to NULL after release", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68238", " - drm/amdgpu: Release VFCT ACPI table reference", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68239", " - drm/ttm: Account for NULL and handle pages in ttm_pool_backup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68241", " - drm/i915/mst: limit DP MST ESI service loop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68243", " - drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68244", " - drm/i915/gem: Do not leak siblings[] on proto context error", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68245", " - drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68247", " - drm/i915/bios: range check LFP Data Block panel_type2", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68248", " - drm/i915: Return NULL on error in active_instance", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68249", " - drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68250", " - drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68251", " - drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68252", " - drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68253", " - drm/i915/hdcp: check streams[] bounds before overflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68255", " - drm/virtio: bound EDID block reads to the response buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68256", " - drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path", " leaks prev_sink reference", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68257", " - drm/amdkfd: fix 32-bit overflow in CWSR total size calculation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68258", " - drm/amdkfd: Check bounds on CRIU restore queue type and mqd size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68259", " - drm/amdkfd: Check bounds in allocate_event_notification_slot", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68260", " - drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68261", " - drm/imagination: fix error checking of pvr_vm_context_lookup()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68262", " - drm/imagination: Fix user array stride in pvr_set_uobj_array()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68263", " - drm/imagination: Fix double call to drm_sched_entity_fini()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68266", " - drm/xe: Hold a dma-buf reference for imported BOs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68268", " - drm/xe: Return error on non-migratable faults requiring devmem", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68269", " - drm/i915/gem: Add missing nospec on parallel submit slot", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68270", " - drm/sysfb: Avoid possible truncation with calculating visible size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68271", " - drm/nouveau: fix reversed error cleanup order in ucopy functions", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68272", " - drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68275", " - drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68276", " - drm/amdgpu/gfx: fix cleaner shader IB buffer overflow", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68277", " - drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68437", " - drm/imagination: Fit paired fragment job in the correct CCCB", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68278", " - drm/dp/mst: fix buffer overflows in sideband chunk accumulation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68279", " - drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68280", " - drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68281", " - drm/imagination: Count paired job fence as dependency in prepare_job()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68282", " - drm/rockchip: analogix_dp: Add missing error check for", " platform_get_resource()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68284", " - bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68290", " - rds: tcp: unregister sysctl before tearing down listen socket", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68292", " - ice: prevent tstamp ring allocation for non-PF VSI types", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68293", " - net/mlx5: Fix MCIA register buffer overflow on 32 dword reads", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68294", " - net: qrtr: restrict socket creation to the initial network namespace", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68296", " - net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64575", " - bpf: tcp: fix double sock release on batch realloc", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68297", " - tipc: fix u16 MTU truncation in media and bearer MTU validation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68298", " - drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68299", " - vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68300", " - sctp: auth: verify auth requirement when auth_chunk is NULL", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68301", " - net: hsr: fix memory leak on slave unregistration by removing synced", " VLANs", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68302", " - amt: re-read skb header pointers after every pull", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68448", " - ovl: check access to copy_file_range source with src mounter creds", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68304", " - wifi: brcmfmac: fix 802.1X-SHA256 call trace warning", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68306", " - wifi: mt76: mt7996: fix possible NULL-pointer deref in", " mt7996_mcu_sta_bfer_eht()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68307", " - wifi: mt76: mt7925: fix crash in reset link replay", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68308", " - wifi: mt76: mt7996: check pointer returned by", " mt76_connac_get_he_phy_cap()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68439", " - wifi: mt76: mt7925: fix possible NULL-pointer deref in", " mt7925_mcu_bss_he_tlv()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68309", " - wifi: mt76: connac: fix possible NULL-pointer deref in", " mt76_connac_mcu_uni_bss_he_tlv()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68310", " - wifi: mt76: mt7915: guard HE capability lookups", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68311", " - wifi: mt76: mt7925: guard link STA in decap offload", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68313", " - tipc: fix infinite loop in __tipc_nl_compat_dumpit", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64576", " - nexthop: initialize extack in nh_res_bucket_migrate()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64577", " - gtp: check skb_pull_data() return in gtp1u_send_echo_resp()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68314", " - net: mctp i3c: clean up notifier and buses if driver register fails", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68315", " - sctp: validate stream count in sctp_process_strreset_inreq()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68317", " - pds_core: fix auxiliary device add/del races", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68318", " - pds_core: fix use-after-free on workqueue during remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68319", " - pds_core: fix deadlock between reset thread and remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68320", " - sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68321", " - net: txgbe: fix FDIR filter leak on remove", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68324", " - iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68325", " - iommu/amd: Bound the early ACPI HID map", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68326", " - wifi: mwifiex: bound uAP association event IEs to the event buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68327", " - wan: wanxl: Only reset hardware after BAR mapping", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68328", " - nfp: Check resource mutex allocation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64574", " - wifi: mac80211: tear down new links on vif update error path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68329", " - iommu/amd: Wait for completion instead of returning early in", " iommu_completion_wait()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68330", " - net: airoha: Fix DMA direction for NPU mailbox buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68331", " - dpaa2-eth: put MAC endpoint device on disconnect", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68332", " - net: airoha: Fix potential use-after-free in airoha_ppe_deinit()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68333", " - dpaa2-switch: put MAC endpoint device on disconnect", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68334", " - rxrpc: fix io_thread race in rxrpc_wake_up_io_thread()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68335", " - rds: drop incoming messages that cross network namespace boundaries", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68336", " - bonding: fix devconf_all NULL dereference when IPv6 is disabled", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68338", " - net/packet: avoid fanout hook re-registration after unregister", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68339", " - Bluetooth: btusb: validate Realtek vendor event length", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68340", " - hwmon: occ: validate poll response sensor blocks", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68341", " - ovpn: fix use after free in unlock_ovpn()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68342", " - ovpn: avoid putting unrelated P2P peer on socket release", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68343", " - smb: client: validate DFS referral PathConsumed", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68346", " - ALSA: hda: cs35l41: validate and free ACPI mute object", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68348", " - ASoC: tas2781: bound firmware description string parsing", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68450", " - btrfs: free mapping node on duplicate reloc root insert", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68442", " - btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68349", " - wifi: carl9170: fix buffer overflow in rx_stream failover path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68350", " - wifi: carl9170: fix OOB read from off-by-two in TX status handler", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68351", " - wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68352", " - wifi: ath6kl: fix OOB read from firmware IE lengths in connect event", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68353", " - wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68354", " - firewire: net: Fix fragmented datagram reassembly", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68355", " - wifi: ath11k: fix potential buffer underflow in", " ath11k_hal_rx_msdu_list_get()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68356", " - watchdog: airoha: Prevent division by zero when clock frequency is zero", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68357", " - watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68358", " - hwmon: (nzxt-kraken3) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68359", " - hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68443", " - hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68360", " - hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68361", " - hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68362", " - wifi: ath11k: fix NULL pointer dereference in", " ath11k_hal_srng_access_begin", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68363", " - wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware", " request", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68365", " - USB: serial: io_edgeport: cap received transmit credits", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68366", " - usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64583", " - usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before", " teardown", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68368", " - usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68369", " - usb: gadget: printer: fix infinite loop in printer_read()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64584", " - usb: gadget: f_midi: cancel pending IN work before freeing the midi", " object", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68370", " - usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68371", " - usb: musb: omap2430: Do not put borrowed of_node in probe", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68373", " - wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68374", " - usb: core: sysfs: add lock to bos_descriptors_read()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64569", " - mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68376", " - sctp: fix auth_hmacs array size in struct sctp_cookie", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68377", " - net/sched: act_tunnel_key: Defer dst_release to RCU callback", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68378", " - dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68379", " - tcp: fix TIME_WAIT socket reference leak on PSP policy failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68380", " - accel/amdxdna: Fix use-after-free of mm_struct in job scheduler", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64578", " - ksmbd: validate compound request size before reading StructureSize2", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68381", " - ksmbd: pin conn during async oplock break notification", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68384", " - drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68385", " - s390/checksum: Fix csum_partial() without vector facility", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68386", " - bpf, sockmap: Reject unhashed UDP sockets on sockmap update", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68387", " - can: raw: add locking for raw flags bitfield", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68388", " - smb/client: handle overlapping allocated ranges in fallocate", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68389", " - Bluetooth: hci_qca: Clear memdump state on invalid dump size", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68391", " - Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68392", " - Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68393", " - Bluetooth: hci_sync: extend conn_hash lookup critical sections", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68394", " - Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64573", " - Bluetooth: qca: fix NVM tag length underflow in TLV parser", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68449", " - ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-", " scanning", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68395", " - ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is", " registered", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68396", " - scsi: core: wake eh reliably when using scsi_schedule_eh", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68397", " - net/iucv: take a reference on the socket found in afiucv_hs_rcv()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64572", " - ipv4: fib: free fib_alias with kfree_rcu() on insert error path", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68398", " - ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68400", " - firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset", " calculation", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68401", " - firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68402", " - wifi: cfg80211: bound element ID read when checking non-inheritance", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68403", " - wifi: brcmfmac: initialize SDIO data work before cleanup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68405", " - wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68406", " - wifi: cfg80211: validate PMSR FTM preamble range", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68407", " - wifi: nl80211: free RNR data on MBSSID mismatch", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68408", " - wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64571", " - wifi: p54: validate RX frame length in p54_rx_eeprom_readback()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68409", " - wifi: mac80211: defer link RX stats percpu free to RCU", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68410", " - wifi: libertas: fix memory leak in helper_firmware_cb()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64570", " - wifi: mac80211: fix fils_discovery double free on alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64568", " - wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68411", " - wifi: mac80211_hwsim: clamp virtio RX length before skb_put", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68412", " - wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68413", " - wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68414", " - wifi: cfg80211: cancel sched scan results work on unregister", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64579", " - xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64580", " - xfrm6: clear dst.dev on error to avoid double netdev_put in", " xfrm6_fill_dst()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64566", " - xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68415", " - xfrm: clear mode callbacks after failed mode setup", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68416", " - mtd: fix double free and WARN_ON in add_mtd_device() error paths", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68417", " - RDMA/siw: publish QP after initialization", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68418", " - RDMA/irdma: Prevent user-triggered null deref on QP create", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68419", " - RDMA/irdma: Prevent rereg_mr for non-mem regions", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68420", " - xfrm: reject optional IPTFS templates in outbound policies", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68421", " - sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68444", " - firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68422", " - btrfs: fix root leak if its reloc root is unexpected in", " merge_reloc_roots()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64567", " - btrfs: reject free space cache with more entries than pages", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68425", " - IB/mad: Drop unmatched RMPP responses before reassembly", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68426", " - xfrm: fix stale skb->prev after async crypto steals a GSO segment", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64565", " - Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68427", " - gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-68428", " - KVM: x86/mmu: Fix use-after-free on vendor module reload", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64562", " - KVM: nVMX: Hide shadow VMCS right after VMCLEAR", " * Resolute update: upstream stable patchset 2026-08-26 (LP: #2165189) //", " CVE-2026-64561", " - KVM: x86: Check for invalid/obsolete root *after* making MMU pages", " available", " * resolute: llvm-21-dev build-depends breaks cross-builds (LP: #2165407)", " - [Packaging] Fix cross-builds", " * Resolute Stable Update v6.18.40, v7.1.5 bugs (LP: #2165040)", " - accel/amdxdna: Allow forcing IOVA-based DMA via module parameter", " - SAUCE: bpf: Add missing NULL argument to zap_page_range_single", " - accel/amdxdna: Return ERR_PTR on dma_alloc_noncoherent failure", " - accel/amdxdna: Fix memory leak in amdxdna_iommu_alloc()", " * [SRU][HPE] Take Intel platform into account for old microcode checks", " (LP: #2161748)", " - x86/microcode: Refactor platform ID enumeration into a helper", " - x86/cpu: Add platform ID to CPU info structure", " - x86/cpu: Add platform ID to CPU matching structure", " - x86/microcode: Add platform mask to Intel microcode \"old\" list", " - x86/microcode: Do not access MSR_IA32_PLATFORM_ID when running as a", " guest", " * ice: E810 interface fails to initialize (ice_init_hw failed: -5) during", " NVM read (LP: #2163508)", " - ice: acquire NVM lock around each flash read", " * WWAN modem unresponsive after freeze on Dell systems with DW5826e", " (LP: #2163214)", " - platform/x86: dell-dw5826e: Add reset driver for DW5826e", " - platform/x86: dell-dw5826e: fix ACPI _DSM function index and bitmask", " usage", " - [Config] Add CONFIG_DELL_DW5826E_RESET=m", " * amdgpu panel self-refresh on dual-gpu laptops causes complete built-in", " panel freeze and severe system instability (LP: #2162904)", " - SAUCE: drm/amdgpu: Do not enter PSR if multiple displays are active", " * linux 7.0: dw9719 VCM never binds, disabling all IPU3 cameras (regression,", " fixed upstream) (LP: #2162045)", " - media: dw9719: Add back the I²C device id table", " * Fix TAS2783 SoundWire amp resume timeout >5s (LP: #2164967)", " - soundwire: Add a helper function to wait for device initialisation", " - ASoC: tas2783: Use new SoundWire enumeration helper", " - soundwire: Move wait for initialisation helper to header", " - ASoC: codecs: tas2783-sdw: Propagate regcache_sync() errors", " - ASoC: tas2783-sdw: drop stale regcache on uninitialized re-attach", " * Linux, Ubuntu, 24.04, System hangs for about 10 seconds when unplug", " external monitor cable on non TBT dock (LP: #2160082)", " - SAUCE: drm/i915/tc: Revert forced DP-alt connected workaround", " * Speakers not detected on HP systems with TI TAS2783 SoundWire amps", " (LP: #2164504)", " - ASoC: sdw_utils: Add missed component_name strings for TI amps", " * [TWL][Desktop] intel_dmc_wait_fw_load() merge to Ubuntu next release", " (LP: #2156316)", " - SAUCE: drm/i915/dmc: fix assert_dmc_loaded WARN during async firmware", " load", " * 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", " * Ethernet adapter unusable after suspend/resume on Advantech systems with", " Intel I226-V (LP: #2163375)", " - igc: fix netdev not re-attached after resume if interface is down", " * ice: fix stale -EBUSY on resume of Intel E810 (LP: #2162803)", " - ice: wait for reset completion in ice_resume()", " * idxd: crash-kernel NULL-pointer Oops in `destroy_workqueue()` breaks kdump", " on Intel DSA/IAA systems (LP: #2163062)", " - SAUCE: dmaengine: idxd: Do not call destroy_workqueue with null idxd->wq", " - SAUCE: dmaengine: idxd: fix duplicate memory frees on initialization", " error path.", " * [HP][ZBook Power 16 G11] Laptop freezed after upgrading the BIOS", " (LP: #2132119)", " - PCI/ASPM: Avoid L0s for Realtek RTS525A", " * Fix noise of audio output on more Dell QCx1255 models after reboot", " (LP: #2163293)", " - ALSA: hda/realtek - Add quirk for Dell Pro QC1255", " * Fix no audio input/output device on Dell WCL Slate platform with", " CirrusLogic audio solution (LP: #2160200)", " - ASoC: SDCA: fix the register to ctl value conversion for Q7.8 format", " - ASoC: SOF: ipc4-control: Use local copy of IPC message for sending", " * Fix no audio output and mute hotkey not working on HP ZBook 8 G2a", " (LP: #2158858)", " - ALSA: hda/realtek: Add inverted LED quirk for HP ZBook 8 G2a", " * Dock ethernet stops working after Thunderbolt dock unplug on Dell systems", " (LP: #2162704)", " - usb: core: port: Deattach Type-C connector on component unbind", " * USB-C alt mode dropped with false firmware bug warning on Dell systems", " (LP: #2162695)", " - Revert \"usb: typec: ucsi: Detect and skip duplicate altmodes from buggy", " firmware\"", " - Revert \"usb: typec: ucsi: Add duplicate detection to nvidia registration", " path\"", " - Revert \"usb: typec: ucsi: yoga_c630: Remove redundant duplicate altmode", " handling\"", " - usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware", " - usb: typec: ucsi: Add duplicate detection to nvidia registration path", " - usb: typec: ucsi: yoga_c630: Remove redundant duplicate altmode handling", " * Resolute update: upstream stable patchset 2026-08-20 (LP: #2164666)", " - crypto: algif_skcipher - force synchronous processing", " - crypto: sun4i-ss - Remove insecure and unused rng_alg", " - [Config] Remove unused CRYPTO_DEV_SUN4I_SS_PRNG", " - media: uvcvideo: Fix deadlock if uvc_status_stop is called from", " async_ctrl.work", " - bpf: Clear delta when clearing reg id for non-{add,sub} ops", " - selftests/bpf: Add tests for delta tracking when src_reg == dst_reg", " - selftests/bpf: Add tests for stale delta leaking through id reassignment", " - ALSA: hda/realtek: Add quirk for TongFang X6xx45xU", " - ALSA: hda: conexant: Remove mic bias threshold override", " - ALSA: hda: Fix cached processing coefficient verbs", " - ALSA: hda/realtek: Fix speakers on Legion Pro 7 16ARX8H with codec SSID", " 17aa:38a7", " - media: uvcvideo: Use hw timestaming if the clock buffer is full", " - media: uvcvideo: Avoid partial metadata buffers", " - media: uvcvideo: Fix buffer sequence in frame gaps", " - media: uvcvideo: Fix dev_sof filtering in hw timestamp", " - media: uvcvideo: Do not add clock samples with small sof delta", " - media: uvcvideo: Relax the constrains for interpolating the hw clock", " - 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: max310x: implement gpio_chip::get_direction()", " - serial: 8250_omap: clear rx_running on zero-length DMA completes", " - rxrpc: rxrpc_verify_data ensure rx_dec_buffer alloc", " - rxrpc: Fix socket notification race", " - rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)", " - rxrpc: Fix potential infinite loop in rxrpc_recvmsg()", " - rxrpc: Fix rxrpc_rotate_tx_rotate() to check there's something to rotate", " - rxrpc: Fix oob challenge leak in cleanup after notification failure", " - rxrpc: Fix ACKALL packet handling", " - rxrpc: Fix the reception of a reply packet before data transmission", " - rxrpc: Fix leak of connection from OOB challenge", " - afs: fix NULL pointer dereference in afs_get_tree()", " - afs: handle CB.InitCallBackState3 requests without a server record", " - afs: Fix uncancelled rxrpc OOB message handler", " - fbcon: fix NULL pointer dereference for a console without vc_data", " - fbcon: Use correct type for vc_resize() return value", " - openrisc: mm: Fix section mismatch between map_page and __set_fixmap", " - clocksource/drivers/sun5i: Handle error returns from", " devm_reset_control_get_optional_exclusive()", " - accel/amdxdna: Fix leak when pinning ubuf pages", " - drm/rockchip: dw_dp: Switch to drmm_kzalloc()", " - drm/rockchip: dw_dp: Fix null-ptr-deref in dw_dp_remove()", " - drm/rockchip: Test for imported buffers with drm_gem_is_imported()", " - drm/tidss: Drop extra drm_mode_config_reset() call", " - drm/gpusvm: Reject VMAs with VM_IO or VM_PFNMAP when creating SVM ranges", " - drm/gpuvm: Do not prepare NULL objects", " - 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", " - selftests/bpf: Fix off-by-one in bpf_cpumask_populate related selftest", " - dt-bindings: timer: Remove sifive,fine-ctr-bits property", " - drm/amd/pm: remove trailing semicolon from AMDGPU_PM_POLICY_ATTR macro", " - selftests/bpf: Use local type for flow_offload_tuple_rhash in", " xdp_flowtable", " - selftests/bpf: Use local type for bpf_fou_encap in test_tunnel_kern", " - Documentation: proc: fix section numbering in table of contents", " - arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Cobra", " - arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S", " - arm64: dts: qcom: ipq5424: Fix USB simple_bus_reg warnings", " - arm64: dts: qcom: sc8180x: Fix phy simple_bus_reg warning", " - 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: fix wrong pci_get_drvdata type in AER handlers", " - wifi: rtw88: fix wrong pci_get_drvdata type in AER handlers", " - wifi: rtw89: Correct data type for scan index to avoid infinite loop", " - wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA", " buffer", " - wifi: rtw89: add bounds check on firmware mac_id in link lookup", " - kconfig: fix potential NULL pointer dereference in conf_askvalue", " - soc: xilinx: Shutdown and free rx mailbox channel", " - pinctrl: mediatek: eint: Drop base from mtk_eint_chip_write_mask()", " - wifi: ath9k: fix OOB access from firmware tx status queue ID", " - ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint", " - Documentation/rv: Replace stale website link", " - 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", " - memory: tegra: Wire up system sleep PM ops", " - crypto: qat - fix heartbeat error injection", " - lib/vsprintf: Fix to check field_width and precision", " - dts: spacemit: set console baud rate on bpif3", " - pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path", " - dt-bindings: vendor-prefixes: Add Displaytech Ltd.", " - drm/gpuvm: take refcount on DRM device", " - drm/panel: Clean up S6E3HA2 config dependencies and fill help text", " - ARM: dts: rockchip: Add #{address,size}-cells to Chromium-based", " /firmware", " - arm64: dts: rockchip: Add #{address,size}-cells to Chromium-based", " /firmware", " - arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc", " - arm64: dts: imx8x-colibri: Correct SODIMM PAD settings", " - Revert \"arm64: dts: imx8mm-kontron: Add support for reading SD_VSEL", " signal\"", " - Revert \"arm64: dts: imx8mp-kontron: Add support for reading SD_VSEL", " signal\"", " - drm: renesas: rz-du: mipi_dsi: Fix return path on error", " - alarmtimer: Remove stale return description from alarm_handle_timer()", " - OPP: Fix race between OPP addition and lookup", " - crypto: ccp - Reverse the cleanup order in psp_dev_destroy()", " - crypto: ccp - Fix snp_filter_reserved_mem_regions() off-by-one", " - 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", " - ARM: multi_v7_defconfig: Correct QCOM_RPMH and QCOM_RPMHPD", " - nilfs2: fix backing_dev_info reference leak", " - media: qcom: camss: vfe: fix PIX subdev naming on VFE lite", " - media: iris: scale MMCX power domain on SM8250", " - media: venus: scale MMCX power domain on SM8250", " - iommu/amd: Fix a stale comment about which legacy mode is user visible", " - soc: mediatek: mtk-mmsys: Restore MT8167 routing masks lost during merge", " - bpf: fix crash in bpf_[set|remove]_dentry_xattr for negative dentries", " - uaccess: fix ignored_trailing logic in copy_struct_to_user()", " - arm64: dts: mediatek: mt8192-asurada: Move PCIe DMA bounce buffer to", " host", " - rust: alloc: fix `Vec::extend_with` SAFETY comment", " - clk: scmi: Fix clock rate rounding", " - arm64: dts: qcom: kodiak: Fix ICE reg size", " - arm64: dts: qcom: sm8450: Fix ICE reg size", " - drm/hisilicon/hibmc: add updating link cap in DP detect()", " - drm/hisilicon/hibmc: fix no showing when no connectors connected", " - drm/hisilicon/hibmc: move display contrl config to hibmc_probe()", " - 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()", " - scsi: hisi_sas: Add slave_destroy interface for v3 hw", " - 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)", " - IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier", " - RDMA/hns: Fix arithmetic overflow in calc_hem_config()", " - RDMA/mlx5: Fix UMR XLT cleanup on ODP populate failure", " - RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference", " - RDMA/hns: Initialize seqfile before creating file", " - drm/syncobj: Fix memory leak in drm_syncobj_find_fence()", " - selftests/bpf: Reject unsupported -k option in vmtest.sh", " - selftests/bpf: Fix test for refinement of single-value tnum", " - iommu/arm-smmu-qcom: Fix fastrpc compatible string in ACTLR client match", " table", " - selftests/mm: Fix resv_sz when parsing arm64 signal frame", " - firmware: arm_ffa: Honor partition info descriptor size", " - arm64: dts: imx8dxl-evk: Remove unnecessary PCIe EP properties", " - arm64: dts: imx8qxp-mek: Remove unnecessary PCIe EP vpcie-supply", " - arm64: dts: imx95-19x19-evk: Fix PCIe EP vpcie-supply", " - media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()", " - media: atomisp: gc2235: fix UAF and memory leak", " - staging: media: atomisp: fix loop shadowing in ia_css_stream_destroy()", " - riscv: dts: spacemit: set console baud rate on Milk-V Jupiter", " - firmware: smccc: Fix Arm SMCCC SOC_ID name call", " - firmware: arm_scmi: Read sensor config as 32-bit value", " - sysfs: clamp show() return value in sysfs_kf_read()", " - bitops: use common function parameter names", " - regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions", " - tools/nolibc: getopt: Fix potential out of bounds access", " - nilfs2: Fix return in nilfs_mkdir", " - net/sched: sch_drr: annotate data-races around cl->deficit", " - media: rockchip: rga: fix too small buffer size", " - firmware: arm_scmi: Fix OOB in scmi_power_name_get()", " - arm64: dts: qcom: lemans: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: monaco: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sc7180: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: kodiak: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8550: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sm8750: Add power-domain and iface clk for ice node", " - tracing: Bound synthetic-field strings with seq_buf", " - arm64: dts: qcom: lemans: Add eDP ref clock for eDP PHYs", " - writeback: drop now-unnecessary rcu_barrier() in", " cgroup_writeback_umount()", " - kernfs: fix suspicious RCU usage in kernfs_put()", " - 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", " - Revert \"treewide: Fix probing of devices in DT overlays\"", " - of: dynamic: Fix overlayed devices not probing because of fw_devlink", " - crypto: eip93 - fix reset ring register definition", " - cpufreq: Documentation: fix sampling_down_factor range", " - cpufreq: conservative: Simplify frequency limit handling", " - pwm: imx27: Fix variable truncation in .apply()", " - RDMA/mana_ib: Use ib_get_eth_speed for reporting port speed", " - bus: sunxi-rsb: Always check register address validity", " - pinctrl: spacemit: fix NULL check in spacemit_pin_set_config", " - 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/hns: Fix log flood after cmd_mbox failure", " - RDMA/counter: Fix incorrect port index in rdma_counter_init() error", " cleanup", " - pinctrl: meson: amlogic-a4: fix gpio output glitch", " - PM: sleep: Use complete() in device_pm_sleep_init()", " - 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", " - driver core: Fix missing jiffies conversion in", " deferred_probe_extend_timeout()", " - driver core: Guard deferred probe timeout extension with", " delayed_work_pending()", " - mtd: spi-nor: debugfs: Fix the flags list", " - mtd: spi-nor: Drop duplicate Kconfig dependency", " - ALSA: xen-front: Reset event channel state on stream clear", " - ALSA: xen-front: Connect event channel after stream prepare", " - ALSA: seq: oss: Fix UAF at handling events with embedded SysEx data", " - ALSA: seq: midi: Serialize output teardown with event_input", " - selftests: Fix Makefile target for nsfs", " - pinctrl: nuvoton: ma35d1: fix MFP register offset and pin table", " - pinctrl: cs42l43: Fix leaked pm reference on error path", " - pinctrl: cs42l43: Fix polarity on debounce", " - init/initramfs_test: wait_for_initramfs() before running", " - nvmet-tcp: fix page fragment cache leak in error path", " - nvmet-tcp: check return value of nvmet_tcp_set_queue_sock", " - nvme-pci: fix out-of-bounds access in nvme_setup_descriptor_pools", " - 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", " - iommu/amd: Fix premature break in init_iommu_one()", " - rtla/actions: Restore continue flag in actions_perform()", " - 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", " - bpftool: Fix typo in struct_ops map FD generation for light skeleton", " - libbpf: Fix UAF in strset__add_str()", " - ARM: tegra: Add #{address,size}-cells to Chromium-based /firmware", " - arm64: tegra: Add #{address,size}-cells to Chromium-based /firmware", " - 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", " - crypto: inside-secure/eip93 - Add check for devm_request_threaded_irq", " - crypto: tegra - Fix dma_free_coherent size error", " - crypto: tegra - Return ENOMEM when input buffer allocation fails for ccm", " - sched/deadline: Reject debugfs dl_server writes for offline CPUs", " - drm/msm/dp: fix HPD state status bit shift value", " - drm/msm/dp: Fix the ISR_* enum values", " - EDAC/igen6: Fix call trace due to missing release()", " - EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in", " skx_get_dimm_info", " - arm64: dts: st: Fix SAI addresses on stm32mp251", " - RDMA/umem: Add ib_umem_is_contiguous() stub for", " !CONFIG_INFINIBAND_USER_MEM", " - RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe", " - RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path", " - Revert \"media: venus: hfi_platform: Correct supported codecs for sc7280\"", " - 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", " - amba: use generic driver_override infrastructure", " - cdx: use generic driver_override infrastructure", " - Drivers: hv: vmbus: use generic driver_override infrastructure", " - rpmsg: use generic driver_override infrastructure", " - raid1: fix nr_pending leak in REQ_ATOMIC bad-block error path", " - bpf: fix BPF_PROG_QUERY OOB write and cgroup backward compat", " - selftests/bpf: add verification for BPF_PROG_QUERY attr size boundaries", " - libbpf: Skip hash computation when loader generation failed", " - libbpf: Skip endianness swap when loader generation failed", " - ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data", " writeback", " - spi: atmel: fix DMA channel and bounce buffer leaks", " - ASoC: rsnd: Fix RSND_SOC_MASK width to single nibble", " - NFSD: Fix delegation reference leak in nfsd4_revoke_states", " - ARM: imx3: Fix CCM node reference leak", " - HID: wiimote: Fix table layout and whitespace errors", " - wifi: ath12k: fix incorrect HT/VHT/HE/EHT MCS reporting in monitor mode", " - wifi: ath12k: fix NULL deref in change_sta_links for unready link", " - ata: libata: Fix ata_exec_internal()", " - ARM: imx31: Fix IIM mapping leak in revision check", " - x86/cpu: Keep the PROCESSOR_SELECT menu together", " - nvdimm/btt: Handle preemption in BTT lane acquisition", " - scsi: Revert \"scsi: Fix sas_user_scan() to handle wildcard and multi-", " channel scans\"", " - bpf: Reject exclusive maps as inner maps in map-in-map", " - libbpf: Reject non-exclusive metadata maps in the signed loader", " - libbpf: Skip initial_value override on signed loaders", " - libbpf: Skip max_entries override on signed loaders", " - 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", " - driver core: Use system_percpu_wq instead of system_wq", " - bpf: Reject exclusive maps for bpf_map_elem iterators", " - tick/sched: Fix TOCTOU in nohz idle time fetch", " - lib/test_meminit: use && for bools", " - riscv: dts: sophgo: sg2044: use hex for CPU unit address", " - riscv: dts: sophgo: sg2042: use hex for CPU unit address", " - configfs_lookup(): don't leave ->s_dentry dangling on failure", " - lockdep/selftests: Restore migrate_disable() state on PREEMPT_RT", " - lockdep/selftests: Restore sched_rt_mutex state on PREEMPT_RT", " - ext4: fix fast commit wait/wake bit mapping on 64-bit", " - drm/amdgpu: set sub_block_index for mca ras sub-blocks", " - bpftool: Use libbpf error code for flow dissector query", " - vhost: fix vhost_get_avail_idx for a non empty ring", " - iommu/vt-d: Fix RB-tree corruption in probe error path", " - perf/x86/amd/core: Always use the NMI latency mitigation", " - perf/x86/intel/uncore: Fix discovery unit lookup for multi-die systems", " - perf/x86/amd/uncore: Use Node ID to identify DF and UMC domains", " - xfrm: fix NAT-related field inheritance in SA migration", " - cxl/fwctl: Fix __fortify_panic", " - drm/amdkfd: always resume_all after suspend_all", " - of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array()", " fails", " - ocfs2: rebase copied fsdlm LVB pointers in locking_state", " - lib: kunit_iov_iter: repeatedly call alloc_pages_bulk()", " - 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: 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", " - netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock", " - ALSA: usb-audio: qcom: Initialize offload control return value", " - x86/cpu: Remove obsolete aperfmperf_get_khz() declaration", " - netfilter: conntrack: revert ct extension genid infrastructure", " - netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper", " is pptp", " - RDMA/hfi1: Open-code rvt_set_ibdev_name()", " - IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()", " - ALSA: hda: fix Kconfig dependency of HD Audio PCI", " - RDMA/irdma: Fix OOB read during CQ MR registration", " - RDMA/irdma: Initialize iwmr->access during MR registration", " - arm64: dts: imx8mp-kontron: Reduce EERAM SPI clock frequency", " - arm64: dts: imx95: Correct PCIe outbound address space configuration", " - arm64: dts: lx2162a-clearfog: use rev2 SoC dtsi", " - arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio codec as", " well", " - arm64: dts: imx8mp-kontron: Fix GPIO for display power switch", " - bpf: Clear rb node linkage when freeing bpf_rb_root", " - bpf: Check tail zero of bpf_map_info", " - 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: cpu_ops: Change return value type of cpu_is_stopped() to bool", " - riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe", " - ALSA: seq: Clear variable event pointer on read", " - bpf: Fix NMI/tracepoint re-entry deadlock on lru locks", " - kunit:tool: Don't write to stdout when it should be disabled", " - powerpc/8xx: implement get_direction() in cpm1", " - bpf: Fix NULL pointer dereference in bpf_task_from_vpid()", " - ACPI: IPMI: Fix message kref handling on dead device", " - cpufreq: Documentation: fix conservative governor freq_step description", " - thermal: testing: reject missing command arguments", " - btrfs: don't force DIO writes to be serialized", " - IB/mlx5: Don't take the rereg_mr fallback without a new translation", " - IB/mlx5: Properly support implicit ODP rereg_mr", " - IB/mlx5: Remove unused mkc bits in mlx5r_umr_update_mr_page_shift()", " - IB/mlx5: Pull the pdn out of the depths of the umr machinery", " - IB/mlx5: Don't mangle the mr->pd inside the rereg callback", " - spi: ep93xx: fix double-free of zeropage on DMA setup failure", " - ASoC: amd: acp-sdw-legacy: Bound DAI link iteration", " - ASoC: amd: acp-sdw-sof: Bound DAI link iteration", " - firmware_loader: Fix recursive lock in device_cache_fw_images()", " - configfs: fix lockless traversals of ->s_children", " - watchdog: unregister PM notifier on watchdog unregister", " - pinctrl: qcom: Fix resolving register base address from device node", " - 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", " - ARM: configs: Drop duplicated CONFIG_EXT4_FS", " - wifi: mt76: mt7925: clean up DMA on probe failure", " - wifi: mt76: use kfree_rcu for offchannel link in mt76_put_vif_phy_link", " - wifi: mt76: mt7996: add missing max_remain_on_channel_duration", " - wifi: mt76: mt7925: fix stale pointer comparisons in change_vif_links", " - wifi: mt76: mt7925: keep TX BA state in the primary WCID", " - wifi: mt76: mt792x: skip MLD header rewrite for 802.3 encap TX", " - wifi: mt76: mt7925: validate skb length in testmode query", " - wifi: mt76: mt7996: Fix possible token leak in mt7996_tx_prepare_skb()", " - wifi: mt76: mt7996: Fix possible NULL pointer dereference in", " mt7996_mac_write_txwi_80211()", " - wifi: mt76: mt7996: fix reading zeroed info->control.flags after", " mt76_tx_status_skb_add()", " - wifi: mt76: mt7996: limit work in set_bitrate_mask", " - 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", " - wifi: mt76: mt7925: fix potential tx_retries underflow", " - wifi: mt76: mt7996: fix potential tx_retries underflow", " - btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()", " - ALSA: aloop: Drop superfluous break", " - gpio: mt7621: fix interrupt banks mapping on gpio chips", " - wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is", " reported", " - fbdev: sm501fb: Fix buffer errors in OF binding code", " - vfs: add FS_USERNS_DELEGATABLE flag and set it for NFS", " - hwmon: (it87) Clamp negative values to zero in set_fan()", " - btrfs: zoned: don't account data relocation space-info in statfs free", " space", " - Revert \"btrfs: fix the file offset calculation inside", " btrfs_decompress_buf2page()\"", " - btrfs: zoned: always set max_active_zones for zoned devices", " - btrfs: annotate lockless read of defrag_bytes in should_nocow()", " - btrfs: fix deadlock cloning inline extent when using flushoncommit", " - igc: skip RX timestamp header for frame preemption verification", " - ASoC: sma1307: Fix uevent string leaks in fault worker", " - IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified", " - NFSD: Handle layout stid in nfsd4_drop_revoked_stid()", " - 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", " - virtio: rtc: tear down old virtqueues before restore", " - virtio_console: read size from config space during device init", " - vduse: Requeue failed read to send_list head", " - tools/virtio: check mmap return value in vringh_test", " - vdpa/octeon_ep: Fix PF->VF mailbox data address calculation", " - vdpa/octeon_ep: fix IRQ-to-ring mapping in interrupt handler", " - ASoC: cs35l56: Fix missing calls to wm_adsp2_remove()", " - ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend fails", " - ext4: fix ERR_PTR(0) in ext4_mkdir()", " - tools: missed broadcast_neigh if_link uapi header", " - netlink: specs: rt-link: missed broadcast-neigh", " - bonding: 3ad: add lacp_strict configuration knob", " - bonding: 3ad: fix carrier when no usable slaves", " - 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()", " - vfio/qat: fix f_pos race in qat_vf_resume_write()", " - bpf: Tighten cgroup storage cookie checks for prog arrays", " - pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag", " - pinctrl: airoha: an7581: add missed gpio32 pin group", " - pinctrl: airoha: an7581: fix misprint in gpio19 pinconf", " - arm64: dts: allwinner: a523: Add missing GPIO interrupt", " - ASoC: cs35l56: Fix possible uninitialized value in", " cs35l56_spi_system_reset()", " - s390/process: Fix kernel thread function pointer type", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for", " non-serdev device", " - Bluetooth: eir: Fix stack OOB write when prepending the Flags AD", " - Bluetooth: hci_event: fix simultaneous discovery stuck in FINDING", " - Bluetooth: hci_core: Fix UAF in hci_unregister_dev()", " - Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path", " - Bluetooth: hci: validate codec capability element length", " - Bluetooth: vhci: validate devcoredump state before side effects", " - fs: efs: remove unneeded debug prints", " - RDMA/mlx5: Remove DCT restrack tracking", " - 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: SOF: Intel: hda-sdw-bpt: select SND_SOF_SOF_HDA_SDW_BPT properly", " - 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: dsa: qca8k: fix led devicename when using external mdio bus", " - 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", " - net: pfcp: allocate per-cpu tstats for PFCP netdevs", " - 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: Unregister cxl_acpi in cxl_test_init() error path", " - 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", " - ALSA: usb-audio: qcom: Guard sideband endpoint removal", " - ALSA: seq: Fix kernel heap address leak in bounce_error_event()", " - spi: xilinx: use FIFO occupancy register to determine buffer size", " - iommu: Avoid copying the user array twice in the full-array copy helper", " - 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", " - virtio_net: do not allow tunnel csum offload for non GSO packets", " - net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net/sched: sch_dualpi2: 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", " - net: watchdog: fix refcount tracking races", " - net: ethernet: mtk_wed: fix loading WO firmware for MT7986", " - net/sched: sch_dualpi2: Add missing module alias", " - bpf: Run generic devmap egress prog on private skb", " - net/mlx5: Check max_macs devlink param value against max capability", " - bpf: Fix setting retval to -EPERM for cgroup hooks not returning errno", " - octeontx2-af: npc: Fix size of entry2cntr_map", " - net: ethernet: mtk_wed: debugfs: correct index in wed_amsdu_show()", " - net: wwan: t7xx: check skb_clone in control TX", " - 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", " - net: bcmgenet: Use weighted round-robin TX DMA arbitration", " - net: airoha: Fix register index for Tx-fwd counter configuration", " - net: airoha: Fix debugfs new-tuple display for IPv4 ROUTE entries", " - kcm: use WRITE_ONCE() when changing lower socket callbacks", " - ALSA: seq: oss: Serialize readq reset state with q->lock", " - ALSA: seq: avoid stale FIFO cells during resize", " - 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: Fix typo in verify_umulti_link_info", " - selftests/bpf: Initialize operation name before use", " - bpf: Fix bpf_get/setsockopt to tos for ipv4-mapped ipv6 socket", " - udf: fix nls leak on udf_fill_super() failure", " - bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()", " - net: remove addr_len argument of recvmsg() handlers", " - sockmap: Fix use-after-free in udp_bpf_recvmsg()", " - 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", " - tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)", " - net: airoha: Fix always-true condition in PPE1 queue reservation loop", " - net: ethernet: oa_tc6: Remove FCS size in RX frame", " - ionic: Fix check in ionic_get_link_ext_stats", " - RDMA/bnxt_re: Free SRQ toggle page after firmware teardown", " - RDMA/bnxt_re: Avoid displaying the kernel pointer", " - RDMA/bnxt_re: Fail DBR related page allocation UAPIs if the feature is", " disabled", " - ksmbd: fix use-after-free in same_client_has_lease()", " - mfd: rsmu: Fix page register setup", " - mfd: cs42l43: Sanity check firmware size", " - ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write", " - 9p: avoid returning ERR_PTR(0) from mkdir operations", " - eventpoll: rename ep_remove_safe() back to ep_remove()", " - eventpoll: expand top-of-file overview / locking doc", " - eventpoll: rename attach_epitem() to ep_attach_file()", " - 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", " - i3c: master: svc: Fix missed IBI after false SLVSTART on NPCM845", " - staging: nvec: fix use-after-free in nvec_rx_completed()", " - perf debuginfo: Fix libdw API contract violations", " - coresight: cti: Fix DT filter signals silently ignored", " - soundwire: don't program SDW_SCP_BUSCLOCK_SCALE on a unattached", " Peripheral", " - soundwire: fix bug in sdw_add_element_group_count found by syzkaller", " - coresight: ete: Always save state on power down", " - 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", " - perf sched: Add missing mmap2 handler in timehist", " - PCI: loongson: Do not ignore downstream devices on external bridges", " - rust: alloc: fix assert in `Vec::reserve` doc test", " - bus: mhi: ep: Fix potential deadlock in mhi_ep_reset_worker()", " - coresight: fix missing error code when trace ID is invalid", " - clk: qcom: cmnpll: Account for reference clock divider", " - phy: phy-can-transceiver: Check driver match and driver data against", " NULL", " - perf pmu: Skip test on Arm64 when #slots is zero", " - clk: at91: sam9x7: Fix gmac_gclk clock definition", " - soundwire: intel_ace2x: release bpt_stream when close it", " - coresight: Fix source not disabled on idr_alloc_u32 failure", " - mailbox: mpfs: fix check for syscon presence in mpfs_mbox_inbox_isr()", " - mailbox: mtk-adsp: fix UAF during device teardown", " - PCI: dwc: Fix signedness bug in fault injection test code", " - perf build-id: Fix off-by-one bug when printing kernel/module build-id", " - 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", " - perf test amd ibs: Fix incorrect kernel version check", " - gpib: Fix inappropriate ioctl error return", " - char: tlclk: fix use-after-free in tlclk_cleanup()", " - gpib: fix double decrement of descriptor_busy in command_ioctl()", " - clk: renesas: rzg2l: Rename iterator in for_each_mod_clock() to avoid", " shadowing", " - powerpc tools perf: Initialize error code in auxtrace_record_init", " function", " - PCI: qcom: Disable ASPM L0s for SA8775P", " - perf header: Sanity check HEADER_EVENT_DESC attr.size before swap", " - 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", " - drm/amd/display: Add missing kdoc for ALLM parameters", " - thunderbolt: debugfs: Fix margining error counter buffer leak", " - dmaengine: imx-sdma: Refine spba bus searching in probe", " - dt-bindings: dma: nvidia,tegra186-gpc-dma: Make reset optional", " - perf: Fix off-by-one stack buffer overflow in kallsyms__parse()", " - perf annotate: Fix crashes on empty annotate windows", " - perf tools: Guard test_bit from out-of-bounds sample CPU", " - perf sched: Fix thread reference leak in latency_switch_event", " - perf tools: Add bounds check to cpu__get_node()", " - perf sched: Cap max_cpu at MAX_CPUS in timehist sample processing", " - perf sched: Fix register_pid() overflow, strcpy, and BUG_ON", " - perf mmap: Guard cpu__get_node() return in aio_bind()", " - perf stat: Bounds-check CPU index in topology aggregation callbacks", " - perf c2c: Bounds-check CPU and node IDs before bitmap and array access", " - perf c2c: Bounds-check CPU IDs in setup_nodes() topology loop", " - perf sched: Clean up idle_threads entry on init failure", " - perf sched: Use thread__put() in free_idle_threads()", " - perf sched: Replace BUG_ON and add NULL checks in replay event helpers", " - perf mmap: Fix NULL deref in aio cleanup on alloc failure", " - perf stat: Introduce perf_env__get_cpu_topology() to guard NULL env->cpu", " - perf c2c: Fix use-after-free in he__get_c2c_hists() error path", " - perf timechart: Fix cpu2y() OOB read on untrusted CPU index", " - perf tools: Fix int16_t truncation of max_cpu_num in set_max_cpu_num()", " - dt-bindings: clock: qcom: Add X1P42100 camera clock controller", " - clk: qcom: camcc-x1e80100: Add support for camera QDSS debug clocks", " - mshv: add bounds check on vp_index in mshv_intercept_isr()", " - dmaengine: qcom: gpi: set DMA_PRIVATE capability", " - dmaengine: Fix possible use after free", " - dmaengine: dma-axi-dmac: Properly free struct axi_dmac_desc", " - dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor", " - clk: qcom: a53: Corrected frequency multiplier for 1152MHz", " - sunrpc: Fix error handling in rpc_sysfs_xprt_switch_add_xprt_store()", " - pNFS/filelayout: fix cheking if a layout is striped", " - 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", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in", " pg_get_mirror_count_write", " - PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro", " - pwm: rzg2l-gpt: Add missing newlines to dev_err_probe() messages", " - PCI: meson: Propagate devm_add_action_or_reset() failure", " - PCI: meson: Add missing remove callback", " - fs/ntfs3: resize log->one_page_buf when adopting on-disk page size", " - platform/x86/intel/vsec: Decouple add/link helpers from PCI", " - platform/x86/intel/vsec: Switch exported helpers from pci_dev to device", " - platform/x86/intel/vsec: Return real error codes from registration path", " - platform/x86/intel/vsec: Restore BAR fallback for header walk", " - perf tools: Fix get_max_num() size_t underflow on empty sysfs file", " - perf tools: Use scnprintf() in cpu_map__snprint() to prevent overflow", " - perf tools: Use perf_env__get_cpu_topology() in machine__resolve()", " - PCI: rcar-host: Remove unused LIST_HEAD(res)", " - perf sched: Bounds-check prio before test_bit() in timehist", " - perf sched: Fix idle-hist callchain display using wrong rb_first variant", " - perf bpf: Use scnprintf() in snprintf_hex() and", " synthesize_bpf_prog_name()", " - perf hists: Fix snprintf() in hists__scnprintf_title() UID filter path", " - xprtrdma: Fix ep kref imbalance on ADDR_CHANGE", " - xprtrdma: Initialize re_id before removal registration", " - xprtrdma: Check frwr_wp_create() during connect", " - xprtrdma: Document and assert reply-handler invariants", " - xprtrdma: Resize reply buffers before reposting receives", " - xprtrdma: Sanitize the reply credit grant after parsing", " - xprtrdma: Repost Receive buffers for malformed replies", " - xprtrdma: Return sendctx slot after Send preparation failure", " - perf s390: Fix TEXTREL in Python extension by compiling as PIC", " - perf cs-etm: Queue context packets for frontend", " - perf pmu: Fix pmu_id() heap underwrite on empty identifier file", " - perf pmu: Fix perf_pmu__parse_scale/unit() OOB access on empty sysfs", " file", " - tools lib api: Fix missing null termination in filename__read_int/ull()", " - perf symbols: Fix signed overflow in sysfs__read_build_id() size check", " - perf symbols: Bounds-check .gnu_debuglink section data", " - perf intel-pt: Fix snprintf size tracking bug in insn decoder", " - perf tools: Fix thread__set_comm_from_proc() on empty comm file", " - perf hwmon: Fix off-by-one null termination on sysfs reads", " - perf hwmon: Use scnprintf() in hwmon_pmu__for_each_event()", " - perf hwmon: Fix parse_hwmon_filename() strlcpy buffer overflow", " - perf symbols: Bounds-check descsz in sysfs__read_build_id() GNU fallback", " - perf hwmon: Guard label read against empty or failed reads", " - perf tools: Use snprintf() in dso__read_running_kernel_build_id()", " - tools lib api: Fix filename__write_int() writing uninitialized stack", " data", " - tools lib api: Fix mount_overload() snprintf truncation and toupper", " range", " - perf bpf: Add NULL check for btf__type_by_id() in", " synthesize_bpf_prog_name()", " - perf bpf: Fix map data leak in bpf_metadata_create() on alloc failure", " - perf bpf: Fix metadata leak in perf_env__add_bpf_info() on duplicate", " insert", " - perf symbols: Add bounds checks to elf_read_build_id() note iteration", " - perf symbols: Add bounds checks to read_build_id() note iteration in", " minimal build", " - dt-bindings: phy: sc8280xp-qmp-pcie: Disallow bifurcation register on", " Purwa", " - PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()", " - PCI: mediatek: Use actual physical address instead of virt_to_phys()", " - phy: freescale: phy-fsl-imx8qm-lvds-phy: Fix missing", " pm_runtime_disable() on probe error path", " - PCI: dwc: Avoid dwc_pcie_rasdes_debugfs_deinit() NULL dereference when", " no RAS DES capability", " - Revert \"PCI/MSI: Unmap MSI-X region on error\"", " - apparmor: fix shadowing of plabel that prevents cache from being updated", " - apparmor: fix race in unix socket mediation when peer_path is used", " - apparmor: fix refcount leak when updating the sk_ctx", " - security/apparmor/apparmorfs.c: conditionally compile", " get_loaddata_common_ref()", " - apparmor: check label build before no_new_privs test", " - apparmor: aa_label_alloc use aa_label_free on alloc failure", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [41/57]: apparmor-next 7.1:", " apparmor: fix rawdata_f_data implicit flex array\"", " - apparmor: fix rawdata_f_data implicit flex array", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [38/57]: apparmor-next 7.1:", " apparmor: grab ns lock and refresh when looking up changehat child", " profiles\"", " - apparmor: grab ns lock and refresh when looking up changehat child", " profiles", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor5.0.0 [44/57]: apparmor-next 7.1:", " apparmor: fix potential UAF in aa_replace_profiles\"", " - apparmor: fix potential UAF in aa_replace_profiles", " - SAUCE: Revert \"UBUNTU: SAUCE: apparmor: fix NULL pointer dereference in", " unpack_pdb\"", " - apparmor: fix NULL pointer dereference in unpack_pdb", " - apparmor: remove or add symlinks to rawdata according to export_binary", " - apparmor: Fix return in ns_mkdir_op", " - apparmor: fail policy unpack on accept2 allocation failure", " - apparmor: aa_getprocattr free procattr leak on format failure", " - apparmor: put secmark label after secid lookup", " - apparmor: don't audit files pointing to aa_null.dentry", " - apparmor: fix uninitialised pointer passed to", " audit_log_untrustedstring()", " - i3c: mipi-i3c-hci: Preserve RUN bit when aborting DMA ring", " - i3c: master: Make hot-join workqueue freezable to block hot-join during", " suspend", " - i3c: master: Move rstdaa error suppression", " - i3c: master: Consolidate Hot-Join DAA work in the core", " - i3c: master: Ensure Hot-Join operations are stopped on shutdown", " - i3c: master: Defer new-device registration out of DAA caller context", " - i3c: master: Prevent reuse of dynamic address on device add failure", " - apparmor: fix label can not be immediately before a declaration", " - accel/ivpu: fix HWS command queue leak on registration failure", " - sparc: led: avoid trimming a newline from empty writes", " - perf symbols: Fix bswap copy-paste error for 32-bit ELF p_filesz", " - perf symbols: Validate p_filesz before use in filename__read_build_id()", " - perf symbols: Break infinite loop on zero-filled notes in", " sysfs__read_build_id()", " - perf tools: Add O_CLOEXEC to open() calls in DSO and ELF code", " - perf tools: Fix uninitialized pathname on uncompressed fallback in", " filename__decompress()", " - perf dso: Fix heap overflow in dso__get_filename() on decompressed path", " - perf dso: Set error code when open() fails on uncompressed fallback path", " - perf tools: Use snprintf() for root_dir path construction", " - perf hwmon: Fix fd check to accept fd 0 in hwmon_pmu__describe_items()", " - perf sched: Replace (void*)1 sentinel with proper runtime allocation", " - perf bpf: Validate func_info_rec_size and sub_id in", " synthesize_bpf_prog_name()", " - perf bpf: Reject oversized BPF metadata events that truncate header.size", " - perf bpf: Bounds-check array offsets in bpil_offs_to_addr()", " - perf cs-etm: Reject CPU IDs that would overflow signed comparison", " - gpio: mlxbf3: fail probe if gpiochip registration fails", " - drm/i915: clear CRTC color blob pointers after dropping refs", " - drm/xe: Fix wa_oob codegen recipe for external module builds", " - spi: dw: fix wrong BAUDR setting after resume", " - i3c: master: Update dev_nack_retry_count under maintenance lock", " - i3c: master: Add missing runtime PM get in dev_nack_retry_count_store()", " - ALSA: usb-audio: qcom: Free sideband sg_table objects", " - xfrm: annotate data-races around xfrm_policy_count[] and", " xfrm_policy_default[]", " - xfrm: validate selector family and prefixlen during match", " - perf machine: Use snprintf() for guestmount path construction", " - perf cs-etm: Validate num_cpu before metadata allocation", " - perf cs-etm: Require full global header in auxtrace_info size check", " - perf cs-etm: Bounds-check CPU in cs_etm__get_queue()", " - perf bpf: Validate array presence before casting BPF prog info pointers", " - perf dso: Set standard errno on decompression failure", " - ASoC: tlv320aic3x: restrict CLKDIV bypass Q values in dual-rate mode", " - drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free", " - drm/amd/display: Fix mem_type change detection for async flips", " - drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm", " - drm/amdgpu: initialize irq.lock spinlock earlier", " - 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", " - ALSA: usb-audio: qcom: reject stream disable with no active interface", " - ALSA: usb-audio: qcom: clear opened when stream enable fails", " - 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()", " - dpaa2-switch: fix VLAN upper check not rejecting bridge join", " - devlink: Fix parent ref leak in devl_rate_node_create()", " - devlink: Fix parent ref leak on tc-bw failure", " - net: airoha: fix foe_check_time allocation size", " - net: macb: add TX stall timeout callback to recover from lost TSTART", " write", " - flow_dissector: check device type before reading ETH_ADDRS", " - selftests: vlan_bridge_binding: Fix flaky operational state check", " - 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: Restore initial state on failed device_rename() in", " cfg802154_switch_netns()", " - ieee802154: Avoid calling WARN_ON() on -ENOMEM in", " cfg802154_switch_netns()", " - ieee802154: Remove WARN_ON() in cfg802154_pernet_exit()", " - ieee802154: fix kernel-infoleak in dgram_recvmsg()", " - mac802154: Prevent overwrite return code in", " mac802154_perform_association()", " - md/raid1: honor REQ_NOWAIT when waiting for behind writes", " - md/raid1: free r1_bio when REQ_NOWAIT is set and read would block on", " retry", " - netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()", " - netfilter: ipset: make sure gc is properly stopped", " - netfilter: nft_payload: reject offsets exceeding 65535 bytes", " - netfilter: nft_meta_bridge: add validate callback for get operations", " - netfilter: nft_flow_offload: zero device address for non-ether case", " - netfilter: nf_reject: skip iphdr options when looking for icmp header", " - netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak", " - mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()", " - irqchip/crossbar: Fix parent domain resource leak", " - alloc_tag: fix use-after-free in /proc/allocinfo after module unload", " - selftests/mm: restore default nr_hugepages value via exit trap in", " charge_reserved_hugetlb.sh", " - selftests/mm: restore default nr_hugepages value via exit trap in", " hugetlb_reparenting_test.sh", " - selftests/mm: fix hugetlb pathname construction in", " hugetlb_reparenting_test.sh", " - selftests/mm: fix cgroup task placement and drop memory.current checks", " in hugetlb_reparenting_test.sh", " - selftests/mm: size tmpfs according to PMD page size in", " split_huge_page_test", " - selftests/mm: free dynamically allocated PMD-sized buffers in", " split_huge_page_test", " - selftest/mm: register existing mapping with userfaultfd in hugetlb-", " mremap", " - selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap", " - selftests/mm: skip uffd-stress test when nr_pages_per_cpu is zero", " - 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", " - net: emac: Fix NULL pointer dereference in emac_probe", " - net/sched: act_ct: fix nf_connlabels leak on two error paths", " - net: airoha: Fix skb->priority underflow in airoha_dev_select_queue()", " - ipv6: ndisc: fix NULL deref in accept_untracked_na()", " - dpaa2-switch: do not accept VLAN uppers while bridged", " - 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", " - bpftool: Fix vmlinux BTF leak in cgroup commands", " - bpf: zero-initialize the fib lookup flow struct", " - bpf: Fix effective prog array index with BPF_F_PREORDER", " - power: sequencing: fix ABBA deadlock in pwrseq_device_unregister()", " - gpiolib: initialize return value in gpiochip_set_multiple()", " - 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()", " - ice: call netif_keep_dst() once when entering switchdev mode", " - rtc: isl1208: Balance enable_irq_wake() with disable_irq_wake() on", " cleanup", " - 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", " - i40e: Fix i40e_debug() to use struct i40e_hw argument", " - rtc: msc313: fix NULL deref in shared IRQ handler at probe", " - ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().", " - eth: bnxt: rename ring_err_stats -> ring_drv_stats", " - eth: bnxt: improve the timing of stats", " - ipv4: fib: Don't ignore error route in local/main tables.", " - md/raid5: use stripe state snapshot in break_stripe_batch_list()", " - md/raid5: avoid R5_Overlap races while breaking stripe batches", " - 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", " - gpio: davinci: fix IRQ domain leak on devm_kzalloc failure", " - 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: do not acquire dev->tx_global_lock in netdev_watchdog_up()", " - net: dsa: sja1105: round up PTP perout pin duration", " - veth: fix NAPI leak in XDP enable error path", " - net: usb: lan78xx: restore VLAN and hash filters after link up", " - 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", " - ipv6: fix state corruption during proxy_ndp sysctl restart", " - ipv6: fix missing notification for ignore_routes_with_linkdown", " - eth: fbnic: fix ordering of heartbeat vs ownership", " - thermal: testing: zone: Flush work items during cleanup", " - ACPI: processor_idle: Mark LPI enter functions as __cpuidle", " - 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: dsa: realtek: fix memory leak in rtl8366rb_setup_led()", " - net: phy: realtek: Clear MDIO_AN_10GBT_CTRL_ADV10G bit", " - octeontx2-af: Validate NIX maximum LFs correctly", " - 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", " - LoongArch: Move struct kimage forward declaration before use", " - LoongArch: BPF: Fix outdated tail call comments", " - LoongArch: BPF: Fix off-by-one error in tail call", " - ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count", " - net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync", " - dt-bindings: net: renesas,ether: Drop example \"ethernet-phy-", " ieee802.3-c22\" fallback", " - selftests: tls: size splice_short pipe by page size", " - 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", " - ALSA: FCP: Fix NULL pointer dereference in interface lookup", " - tracing: probes: fix typo in a log message", " - spi: sh-msiof: abort transfers when reset times out", " - ACPI: RIMT: Only defer the IOMMU configuration in init stage", " - riscv: Fix 32-bit call_on_irq_stack() frame pointer ABI", " - gpio: mvebu: fail probe if gpiochip registration fails", " - gpio: htc-egpio: use managed gpiochip registration", " - net: pse-pd: scope pse_control regulator handle to kref lifetime", " - seg6: validate SRH length before reading fixed fields", " - qede: fix out-of-bounds check for cqe->len_list[]", " - sctp: fix SCTP_RESET_STREAMS stream list length limit", " - MIPS: DEC: Ensure RTC platform device deregistration upon failure", " - MIPS: mm: Add check for highmem before removing memory block", " - ASoC: codecs: lpass-va-macro: Fix LPASS Codec Version for SC7280", " - hwmon: adm1275: Prevent reading uninitialized stack", " - hwmon: (pmbus) Fix passing events to regulator core", " - hwmon: (aspeed-g6-pwm-tach) Guard fan RPM calculation against divide-by-", " zero", " - ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump", " - usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()", " - net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy", " - net: libwx: fix VMDQ mask for 1-queue mode", " - 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", " - drm/panthor: Fix potential invalid pointer deref in", " group_process_tiler_oom()", " - drm/panthor: Don't overrule pending immediate ticks in", " sched_resume_tick()", " - drm/panthor: Fix a leak when a group is evicted before the tiler OOM is", " serviced", " - drm/panthor: Interrupt group start/resumption if group_bind_locked()", " fails", " - tracing/eprobes: Allow use of BTF names to dereference pointers", " - tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg", " - tracing/events: Fix to check the simple_tsk_fn creation", " - tracing: eprobe: read the complete FILTER_PTR_STRING pointer", " - tracing/fprobe: Fix NULL pointer dereference in fprobe_fgraph_entry()", " - tracing/probes: Make the $ prefix mandatory for comm access", " - irqchip/gic-v3-its: Fix OF node reference leak", " - irqchip/ts4800: Fix missing chained handler cleanup on remove", " - sctp: fix addr_wq_timer race in sctp_free_addr_wq()", " - virtio_net: disable cb when NAPI is busy-polled", " - cxgb4: Fix decode strings dump for T6 adapters", " - selftests: drv-net: tso: don't touch dangerous feature bits", " - 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: dualpi2: clear stale classification on filter miss", " - 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: Fix double netfs initialisation in afs_root_iget()", " - afs: use kvfree() to free memory allocated by kvcalloc()", " - afs: Remove erroneous seq |= 1 in volume lookup loop", " - afs: Fix bulk lookup malfunction due to change in dir_emit() API", " - afs: Fix misplaced inc of net->cells_outstanding", " - afs: Fix reinitialisation of the inode, in particular ->lock_work", " - afs: Fix callback service message parsers to pass through -EAGAIN", " - afs: Fix missing NULL pointer check in afs_break_some_callbacks()", " - afs: Fix vllist leak", " - afs: Fix lack of locking around modifications of net->cells_dyn_ino", " - afs: Fix premature cell exposure through /afs", " - 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", " - ovl: fix comment about locking order", " - iomap: guard io_size EOF trim against concurrent truncate underflow", " - netfs: Fix writethrough to use collection offload", " - netfs: Fix writeback error handling", " - netfs: Fix folio state after ENOMEM whilst under writeback iteration", " - drm/xe/pt: Fix NULL pointer dereference in xe_pt_zap_ptes_entry()", " - drm/xe/userptr: Hold notifier_lock for write on inject test path", " - drm/xe/hw_engine: Fix double-free of managed BO in error path", " - drm/xe/pf: Don't attempt to process FAST_REQ or EVENT relays", " - x86/uprobes: Keep shadow stack in sync for emulated CALLs", " - uprobes/x86: Use proper mm_struct in __in_uprobe_trampoline", " - cifs: Fix missing credit release on failure in cifs_issue_read()", " - ata: sata_gemini: unwind clocks on IDE pinctrl errors", " - ata: libata-scsi: limit simulated SCSI command copy to response length", " - 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: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()", " - HID: bpf: Fix hid_bpf_get_data() range check", " - selftests/hid: Load only requested struct_ops maps", " - selftests/hid: Cover hid_bpf_get_data() size overflow", " - arm64/sysreg: Fix BWE field encoding in ID_AA64DFR2_EL1", " - net: usb: net1080: validate packet_len before pad-byte access in", " rx_fixup", " - netfilter: xt_u32: reject invalid shift counts", " - netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()", " - netfilter: nft_set_rbtree: get command skips end element with open", " interval", " - netfilter: xt_connmark: reject invalid shift parameters", " - net/mlx5: LAG, MPESW, Fix missing complete() on devcom error", " - net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation", " - net/mlx5e: Fix HV VHCA stats agent registration race", " - net/mlx5e: Fix publication race for priv->channel_stats[]", " - net: microchip: vcap: fix races on the shared Super VCAP block", " - net: qualcomm: rmnet: validate MAP frame length before ingress parsing", " - net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload", " - 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: sco: Fix a race condition in sco_sock_timeout()", " - Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length", " - Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()", " - Bluetooth: L2CAP: fix tx ident leak for commands without a response", " - ring-buffer: Fix event length with forced 8-byte alignment", " - accel/amdxdna: Use unsigned long for nr_pages in amdxdna_hmm_register()", " - net/tls: Consume empty data records in tls_sw_read_sock()", " - net: usb: lan78xx: disable VLAN filter in promiscuous mode", " - gpio: dwapb: reduce allocation to single kzalloc", " - gpio: dwapb: Defer clock gating until noirq", " - tracing: Make tracepoint_printk static as not exported", " - accel/amdxdna: Fix potential amdxdna_umap lifetime race", " - drm/v3d: Reject invalid indirect BO handle in indirect CSD setup", " - net: mdio: select REGMAP_MMIO instead of depending on it", " - net/sched: cake: reject overhead values that underflow length", " - octeontx2-pf: check DMAC extraction support before filtering", " - perf/x86/amd/core: Avoid enabling BRS from the SVM reload path", " - gpio: mvebu: free generic chips on unbind", " - ipv4: igmp: annotate data-races around im->users", " - ipv4: igmp: annotate data-races around timer-related fields", " - ipv4: igmp: Fix potential memory leaks in igmp_mod_timer() and", " igmp_stop_timer()", " - ipvs: pass parsed transport offset to state handlers", " - ipvs: use parsed transport offset in TCP state lookup", " - s390/zcrypt: Remove the empty file", " - SUNRPC: release lower rpc_clnt if killed waiting for XPRT_LOCKED", " - 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", " - drm/xe: remove duplicate include", " - smb: client: fix overflow in passthrough ioctl bounds check", " - idpf: add padding to PTP virtchnl structures", " - 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", " - octeontx2-pf: clear stale mailbox IRQ state before request_irq()", " - octeontx2-vf: clear stale mailbox IRQ state before request_irq()", " - arm64: fpsimd: Fix type mismatch in sve_{save,load}_state()", " - arm64: dts: s32g3: Fix SWT8 watchdog address", " - ARM: dts: imx6ul-var-som: fix warning for non-existent dc-supply", " property", " - arm64: dts: qcom: sdm630: describe adsp_mem region properly", " - arm64: dts: rockchip: fix Ethernet PHY not found on PX30 Ringneck", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix ADC sampling times", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move divergent mecio1 ADC", " channels to board files", " - arm64: dts: ti: k3-am62a7-sk: Add bootph-all tag to vqmmc", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Enable internal ADC reference", " - arm64: dts: imx8ulp-evk: Correct Type-C int GPIO flags", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix GPIO names typo", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move gpio-line-names to board", " files", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Fix expander gpio line typo", " - ARM: dts: stm32: stm32mp15x-mecio1-io: Move expander gpio-line-names to", " board files", " - LoongArch: KVM: Validate irqchip index in irqfd routing", " - 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()", " - powerpc/pseries/Kconfig: Enable CONFIG_VPA_PMU to be used with KVM", " - KVM: s390: pci: Fix GISC refcount leak on AIF enable failure", " - KVM: s390: pci: Fix handling of AIF enable without AISB", " - KVM: SEV: Do not allow intra-host migration/mirroring of SNP VMs", " - KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs", " - KVM: x86: Nullify irqfd->producer if updating IRTE for bypass fails", " - KVM: nVMX: Put vmcs12 pages if nested VM-Enter fails due to invalid", " guest state", " - KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers", " - KVM: arm64: nv: Drop bogus WARN for write to ZCR_EL2", " - KVM: arm64: nv: Write ESR_EL2 for injected nested SError exceptions", " - KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()", " - 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: efifb: fix memory leak in efifb_probe()", " - 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: Check runtime resume during probe", " - ASoC: mediatek: mt8192: Release reserved memory on cleanup", " - ASoC: mediatek: mt8183: Check runtime resume during probe", " - 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: nft_set_pipapo: don't leak bad clone into future transaction", " - 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", " - selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()", " - selinux: fix incorrect execmem checks on overlayfs", " - 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/brs: Fix kernel address leakage", " - perf/x86/amd/lbr: Fix kernel address leakage", " - cpufreq: schedutil: Fix uncleared need_freq_update on the .adjust_perf()", " path", " - cpufreq: intel_pstate: Set non-turbo capacity to HWP_GUARANTEED_PERF()", " - 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: retrieve ethhdr after potential skb realloc on RX", " - 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: ensure minimal ethernet header on TX", " - 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: clean untagged VLAN on netdev registration failure", " - batman-adv: frag: fix primary_if leak on failed linearization", " - batman-adv: mcast: avoid OOB read of num_dests header", " - 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", " - lockd: Plug nlm_file leak when nlm_do_fopen() fails", " - lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure", " - 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()", " - mm/mm_init: fix pageblock migratetype for ZONE_DEVICE compound pages", " - power: supply: cpcap-battery: Fix missing nvmem_device_put() causing", " reference leak", " - power: supply: max17042: fix OF node reference imbalance", " - mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch", " - mm/memory_hotplug: fix incorrect altmap passing in error path", " - 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: bound NTFS_DE view.data_off in", " UpdateRecordData{Root,Allocation}", " - ntfs3: cap RESTART_TABLE free-chain walker at rt->used", " - ntfs3: fix out-of-bounds read in decompress_lznt", " - landlock: Fix LANDLOCK_SCOPE_SIGNAL bypass on the SIGIO path", " - power: supply: charger-manager: fix refcount leak in is_full_charged()", " - selftests/landlock: Test SCOPE_SIGNAL on the SIGIO/fowner pgid path", " - 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", " - 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()", " - proc: only bump parent nlink when registering directories", " - fs/proc: fix KPF_KSM reported for all anonymous pages", " - powerpc/dt_cpu_ftrs: Set CPU_FTR_P11_PVR for Power11 and later", " processors", " - mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE", " - kcov: use WRITE_ONCE() for selftest mode stores", " - mtd: slram: remove failed entries from the device list", " - 9p: skip nlink update in cacheless mode to fix WARN_ON", " - power: supply: bq257xx: Fix VSYSMIN clamping logic", " - scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()", " - scsi: sas: Skip opt_sectors when DMA reports no real optimization hint", " - openrisc: Add full instruction cache invalidate functions", " - 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: fix UBSAN array-index-out-of-bounds in ocfs2_sum_rightmost_rec", " - 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: host: pci_generic: Fix the physical function check", " - 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()", " - s390/pkey: Check length in PKEY_VERIFYPROTK ioctl", " - s390/pkey: Check length in pkey_pckmo handler implementation", " - mtd: spi-nor: swp: Improve locking user experience", " - mtd: spi-nor: spansion: use die erase for multi-die devices only", " - mtd: rawnand: Pause continuous reads at block boundaries", " - openrisc: Fix jump_label smp syncing", " - mtd: maps: vmu-flash: fix NULL pointer dereference in initialization", " - taskstats: retain dead thread stats in TGID queries", " - irqchip/crossbar: Use correct index in crossbar_domain_free()", " - tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()", " - tpm: tpm2-sessions: wait for async KPP completion in tpm_buf_append_salt", " - sunrpc: fix uninitialized xprt_create_args structure", " - dmaengine: tegra: Fix burst size calculation", " - dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and", " ABORT_INT_MASK", " - platform/x86: dell-laptop: fix missing cleanups in init error path", " - platform/x86: ISST: Restore SST-PP control to all domains", " - 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", " - platform/x86/amd/pmc: Don't log during intermediate wakeups", " - pkey: Move keytype check from pkey api to handler", " - 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", " - hwmon: (max6697) add missing 'select REGMAP_I2C' to Kconfig", " - i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)", " - i2c: imx: fix locked bus on SMBus block-read of 0 (IRQ)", " - i2c: mediatek: fix WRRD for SoCs without auto_restart option", " - i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()", " - i2c: spacemit: fix spurious IRQ handling returning IRQ_HANDLED", " - ice: fix ice_init_link() error return preventing probe", " - tcp: Decrement tcp_md5_needed static branch", " - ufs: core: tracing: Do not dereference pointers in TP_printk()", " - xen/gntdev: fix error handling in ioctl", " - xfrm: use compat translator only for u64 alignment mismatch", " - 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()", " - NFS: Charge unstable writes by request size, not folio size", " - nvme-apple: Prevent shared tags across queues on Apple A11", " - nvmet: fix refcount leak in nvmet_sq_create()", " - netdev-genl: report NAPI thread PID in the caller's pid namespace", " - can: esd_usb: kill anchored URBs before freeing netdevs", " - can: isotp: use unconditional synchronize_rcu() in isotp_release()", " - can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER", " - can: isotp: serialize TX state transitions under so->rx_lock", " - 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: Reset register bounds before narrowing retval range in", " check_mem_access()", " - bpf,fork: wipe ->bpf_storage before bailouts that access it", " - bpf: Add missing access_ok call to copy_user_syms", " - block: remove redundant GD_NEED_PART_SCAN in add_disk_final()", " - block: fix race in blk_time_get_ns() returning 0", " - block: fix IORING_URING_CMD_REISSUE flags check in blkdev_uring_cmd", " - 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-pcache: reject option groups without values", " - 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: fix leaking uninitialized kernel memory", " - dm-integrity: fix a bug if the bio is out of limits", " - dm-integrity: don't increment hash_offset twice", " - dm-verity: avoid double increment of &use_bh_wq_enabled", " - dm-verity: fix a possible NULL pointer dereference", " - dm-verity: increase sprintf buffer size", " - dm-verity: make error counter atomic", " - dma-fence: Make dma_fence_dedup_array() robust against 0-count input", " - accel/amdxdna: Fix use-after-free in amdxdna_gem_dmabuf_mmap()", " - accel/ivpu: Reject firmware log with size smaller than header", " - 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: 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 - only expose sysfs attributes on control interface", " - 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 firmware leak in async update", " - 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", " - tracing/user_events: Fix use-after-free in user_event_mm_dup()", " - wifi: libertas_tf: fix use-after-free in lbtf_free_adapter()", " - posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu()", " - selftests/ftrace: Drop invalid top-level local in test_ownership", " - cpu: hotplug: Preserve per instance callback errors", " - cpu: hotplug: Bound hotplug states sysfs output", " - gpio: mt7621: more robust management of IRQ domain teardown", " - gpio: tegra: do not call pinctrl for GPIO direction", " - gpio: mt7621: be sure IRQ domain is created before exposing GPIO chips", " - gpio-f7188x: Add support for NCT6126D version B", " - gpio: mt7621: avoid corruption of shared interrupt trigger state", " - gpios: palmas: add .get_direction() op", " - net: sit: require CAP_NET_ADMIN in the device netns for changelink", " - net: ethernet: ti: icssg: guard PA stat lookups", " - 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", " - selftests: net: fix file owner for broadcast_ether_dst test", " - 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", " - net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for", " changelink", " - octeontx2-af: Free BPID bitmap on setup failure", " - 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", " - platform/x86/amd/pmc: Avoid logging \"(null)\" for DMI values", " - net/sched: sch_teql: move rcu_read_lock()/spin_lock() from _bh variants", " - drm/xe/userptr: Stub notifier_lock helpers when DRM_GPUSVM=n", " - pwm: rzg2l-gpt: Fix period_ticks type from u32 to u64", " - LoongArch: Fix nr passing in set_direct_map_valid_noflush()", " - LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()", " - ipmi: Fix user refcount underflow in event delivery", " - ipmi: fix refcount leak in i_ipmi_request()", " - bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()", " - rtc: renesas-rtca3: Fix PIE clear polling condition in alarm setup error", " path", " - 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", " - fhandle: reject detached mounts in capable_wrt_mount()", " - hwmon: (max1619) add missing 'select REGMAP' to Kconfig", " - tracing/probes: Fix double addition of offset for @+FOFFSET", " - net/mlx5: HWS, fix matcher leak on resize target setup failure", " - 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", " - mm/compaction: handle free_pages_prepare() properly in compaction_free()", " - irqchip/irq-riscv-imsic-early: Fix fwnode leak on state setup failure", " - s390/monwriter: Reject buffer reuse with different data length", " - mac802154: remove interfaces with RCU list deletion", " - octeontx2-pf: fix SQB pointer leak on init failure", " - selftests: net: make busywait timeout clock portable", " - llc: fix SAP refcount leak in llc_ui_autobind()", " - ipvs: use parsed transport offset in SCTP state lookup", " - macsec: don't read an unset MAC header in macsec_encrypt()", " - dibs: loopback: validate offset and size in move_data()", " - net: macb: drop in-flight Tx SKBs on close", " - arm64: smp: Fix hot-unplug tearing by forcing unregistration", " - cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()", " - fs/resctrl: Free mon_data structures on rdt_get_tree() failure", " - fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list", " - ata: libata-core: Skip HPA resize for locked drives", " - ata: libata-core: Allow capacity transition to zero for locked drives", " - riscv: Prevent NULL pointer dereference in machine_kexec_prepare()", " - tracing/osnoise: Call synchronize_rcu() when unregistering", " - s390/diag: Add missing array_index_nospec() call to", " memtop_get_page_count()", " - s390/mm: Fix type mismatch in get_align_mask().", " - selftests/rseq: Fix a building error for riscv arch", " - 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", " - selftests/landlock: Skip scoped_signal subtest with MSG_OOB if not", " available", " - selftests/landlock: Fix screwed up pointers in the scoped_signal_test", " - mmc: sdhci-esdhc-imx: restore pinctrl before restoring ios timing on", " resume", " - powerpc/pseries: fix memory leak on krealloc failure in papr_init", " - net/mlx5: free mlx5_st_idx_data on final dealloc", " - wifi: rt2x00: avoid full teardown before work setup in probe", " - wifi: mwifiex: fix roaming to different channel in host_mlme mode", " - wifi: mac80211: fix memory leak in ieee80211_register_hw()", " - wifi: brcmfmac: cyw: fix heap overflow on a short auth frame", " - riscv: vdso: Do not use LTO for the vDSO", " - 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", " - reset: sunxi: fix memory region leak on ioremap failure", " - powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()", " - wifi: cfg80211: validate EHT MLE before MLD ID read", " - wifi: ieee80211: validate MLE common info length", " - 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", " - mmc: block: fix RPMB device unregister ordering", " - mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe()", " method", " - mmc: sdhci-esdhc-imx: remove unnecessary mmc_card_wake_sdio_irq check", " for tuning save/restore", " - mmc: sdhci-esdhc-imx: restore DLL override for DDR modes on resume", " - mmc: sdhci-esdhc-imx: fix esdhc_change_pinstate() to allow default state", " restore", " - mmc: sdhci-esdhc-imx: disable irq during suspend to fix unhandled", " interrupt", " - mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspend", " - mmc: sdhci-esdhc-imx: make non-fatal errors non-blocking in suspend", " - mmc: sdhci-esdhc-imx: fix resume error handling", " - crypto: xilinx-trng - Remove crypto_rng interface", " - 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: hid-sensor-rotation: Fix stale or zero output when reading raw", " values", " - ALSA: scarlett2: Allow selecting config_set by firmware version", " - ALSA: scarlett2: Update offsets for 2i2 Gen 4 firmware 2417", " - firmware_loader: Add cancel helper for async requests", " - ALSA: hda/tas2781: Cancel async firmware request at unbind", " - binder: Use LIST_HEAD() to initialize on stack list head", " - binder: cache secctx size before release zeroes it", " - staging: rtl8723bs: fix spaces around binary operators", " - Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister", " - Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()", " - proc: rename proc_setattr to proc_nochmod_setattr", " - usb: dwc3: Support USB3340x ULPI PHY high-speed negotiation.", " - usb: dwc3: fix dwc3_readl() and dwc3_writel() calls in dwc3_ulpi_setup()", " - usb: atm: ueagle-atm: use dev_dbg() for 'device found' message", " - usb: atm: ueagle-atm: remove function entry/exit debug messages", " - usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()", " - btrfs: remove folio parameter from ordered io related functions", " - KVM: arm64: Ensure level is always initialized when relaxing perms", " - KVM: arm64: Fix propagation of TLBI level in", " kvm_pgtable_stage2_relax_perms()", " - mm/damon/core: always put unsuccessfully committed target pids", " - mm/damon/core: trace esz at first setup", " - samples/damon/mtier: fail early if address range parameters are invalid", " - perf callchain: Handle multiple address spaces", " - soc: fsl: qe_ports_ic: Add missing cleanup on device removal", " - drm/rockchip: inno-hdmi: Switch to drmm_kzalloc()", " - accel/amdxdna: Create shared functions for AIE2 and AIE4", " - Revert \"UBUNTU: SAUCE: accel/amdxdna: Support sensors for column", " utilization\"", " - accel/amdxdna: Support sensors for column utilization", " - accel/amdxdna: Adjust size for copy_to_user()", " - accel/amdxdna: Handle DETACH_DEBUG_BO through config_debug_bo path", " - accel/amdxdna: Fix order of canceled mailbox messages", " - accel/amdxdna: Guard management mailbox channel cleanup against NULL", " pointer", " - drm/amdkfd: fix redundant MQD iterations in GFX v12.1", " - wifi: ath12k: Fix invalid IRQ requests during AHB probe", " - libbpf: Fix deduplication of typedef with base definitions", " - spi: atcspi200: Use helper function devm_clk_get_enabled()", " - spi: atcspi200: fix use-after-free when driver unbind", " - arm64: dts: rockchip: Fix vdec register blocks order on RK3576", " - arm64: dts: rockchip: Update vdec register blocks order on RK3588", " - dt-bindings: net: bluetooth: qualcomm: Fix WCN6855 regulator names", " - x86/bug: Add printf() validation to HAVE_ARCH_BUG_FORMAT_ARGS WARNs", " - arm64: dts: qcom: milos: Reduce rmtfs_mem size to 2.5MiB", " - arm64: dts: qcom: sdm845-oneplus: Drop address from framebuffer node", " - arm64: dts: qcom: sdm845-shift-axolotl: Correct touchscreen sleep state", " - soc: xilinx: Fix race condition in event registration", " - wifi: ath11k: cancel SSR work items during PCI shutdown", " - ixgbe: fix unaligned u32 access in ixgbe_update_flash_X550()", " - objtool/klp: Fix is_uncorrelated_static_local() for Clang", " - objtool/klp: Fix .data..once static local non-correlation", " - objtool/klp: Fix create_fake_symbols() skipping entsize-based sections", " - objtool/klp: Fix handling of zero-length .altinstr_replacement sections", " - objtool/klp: Fix cloning of zero-length section symbols", " - objtool/klp: Fix extraction of text annotations for alternatives", " - objtool/klp: Fix relocation conversion failures for R_X86_64_NONE", " - objtool/klp: Use sym->demangled_name for symbol_name hash", " - objtool/klp: Match symbols based on demangled_name for global variables", " - objtool: Replace iterator callback with for_each_sym_by_mangled_name()", " - objtool: Fix reloc hash collision in find_reloc_by_dest_range()", " - klp-build: Fix hang on out-of-date .config", " - klp-build: Fix checksum comparison for changed offsets", " - riscv: dts: microchip: gpio controllers on mpfs need 2 interrupt cells", " - riscv: dts: microchip: remove gpio hogs from beaglev-fire", " - wifi: cfg80211: restrict LMR feedback check to TB and non-TB ranging", " - drm/panel: Clean up SOFEF00 config dependencies", " - drm/panel: Clean up S6E3FC2X01 config dependencies", " - arm64: dts: marvell: samsung-coreprimevelte: Increase touchscreen", " voltage", " - arm64: dts: imx8mn-vhip4-evalboard-v1: Correct interrupt flags", " - arm64: dts: imx8mn-vhip4-evalboard-v2: Correct interrupt flags", " - crypto: ccp - Check for page allocation failure correctly in TIO", " - crypto: ccp - Initialize data during __sev_snp_init_locked()", " - accel/amdxdna: Fix clflush buffer size", " - ntb: Store original DMA address for future release", " - ntb: Use consistent DMA attributes when freeing DMA mappings", " - riscv: dts: spacemit: k3: add clock tree", " - dts: riscv: spacemit: correct 32k clock frequency", " - arm64: dts: qcom: sdm660: set cdsp compute-cbs' regs properly", " - arm64: dts: qcom: sdm630: set adsp compute-cbs' regs properly", " - arm64: dts: qcom: lemans: Move PCIe devices into soc node", " - sockptr: fix usize check in copy_struct_from_sockptr() for user pointers", " - arm64: dts: mediatek: mt7988a-bpi-r4pro: rework pcie gpio-hog handling", " - rhashtable: give each instance its own lockdep class", " - thermal: hwmon: Register a hwmon device for each thermal zone", " - crypto: ccp/sev-dev-tsm - bail out early when pdev->bus is NULL", " - crypto: safexcel - Fix potential memory leak in safexcel_pci_probe()", " - net/sched: add qdisc_qlen_inc() and qdisc_qlen_dec()", " - net/sched: sch_dualpi2: annotate data-races in dualpi2_dump_stats()", " - tools/rtla: Fix --dump-tasks usage in timerlat", " - rtla: Stop the record trace on interrupt", " - dm: limit target bio polling to one shot", " - selftests/bpf: Override EXTRA_LDFLAGS for static builds", " - sched/fair: Update util_est after updating util_avg during dequeue", " - hfs: fix incorrect inode ID assignment in hfs_new_inode()", " - vfio: selftests: Fix out-of-tree build with make O=", " - vfio: selftests: Allow builds when ARCH=x86", " - vfio/xe: avoid duplicate reset in xe_vfio_pci_reset_done", " - arm64: dts: qcom: kaanapali: Add power-domain and iface clk for ice node", " - arm64: dts: qcom: sdm845-xiaomi-beryllium: Correct IPA FW path", " - ASoC: mediatek: mt8189: Fix probe resource cleanup", " - drm/msm/mdss: correct UBWC programming sequences", " - tools/nolibc: stackprotector: Avoid stalling program startup if crng is", " not init yet", " - ASoC: dapm: Fix widget lookup with prefixed names across DAPM contexts", " - ACPI: PAD: Fix teardown ordering in acpi_pad_remove()", " - wifi: ath12k: fix error unwind on arch_init() failure in PCI probe", " - cpufreq: governor: Fix data races on per-CPU idle/nice baselines", " - cpufreq: governor: Fix stale prev_cpu_nice spike when enabling", " ignore_nice_load", " - dt-bindings: vendor-prefixes: Add Verbatim Corporation", " - drm/tegra: fbdev: Do not assign to struct drm_fb_helper.info", " - rust: devres: add 'static bound to Devres", " - lib/base64: validate before writing in decode tail path", " - rust: uaccess: use INLINE_COPY_TO_USER to guard copy_to_user()", " - uaccess: unify inline vs outline copy_{from,to}_user() selection", " - uaccess: minimize INLINE_COPY_USER-related ifdefery", " - crypto: ccp/tsm - Enable the root port after the endpoint", " - firmware: samsung: acpm: Add devm_acpm_get_by_phandle helper", " - firmware: samsung: acpm: remove compile-testing stubs", " - drm/msm/a8xx: Make a8xx_recover IFPC safe", " - drm/msm/a8xx: Fix RSCC offset", " - EDAC/igen6: Fix memory topology parsing for Panther Lake-H SoCs", " - arm: dts: bcm2711: Fix typo in gpio-line-names", " - arm64: dts: renesas: r8a78000: Fix GIC-720AE View 1 Redistributor", " description", " - arm64: dts: renesas: ironhide: Describe all reserved memory", " - md: replace wait loop with wait_event() in md_handle_request()", " - md/raid1,raid10: fix deadlock in read error recovery path", " - md/raid1,raid10: fix error-path detection with md_cloned_bio()", " - md/raid1,raid10: fix bio accounting for split md cloned bios", " - liveupdate: Use refcount_t for FLB reference counts", " - liveupdate: Reference count incoming FLB data", " - liveupdate: skip serialization for context-preserving kexec", " - liveupdate: fix TOCTOU race in luo_session_retrieve()", " - liveupdate: block session mutations during reboot", " - spi: imx: replace dmaengine_terminate_all() with", " dmaengine_terminate_sync()", " - wifi: ath12k: fix memory leak in ath12k_wifi7_dp_rx_h_verify_tkip_mic()", " - wifi: ath12k: fix inconsistent arvif state in vdev_create error paths", " - ACPI: button: Fix lid_device value leak past driver removal", " - drm/amd/pm: Add empty string validation to sysfs store functions", " - accel/amdxdna: Return errors for failed debug BO commands", " - mm: preserve PG_dropbehind flag during folio split", " - perf/x86/intel/uncore: Fix PCI device refcount leak in UPI discovery", " - wifi: wlcore: enable the right set of ciphers", " - cxl/test: Fix __fortify_panic", " - bpf: Take mmap_lock in zap_pages()", " - ocfs2: fix out-of-bounds write in ocfs2_remove_refcount_extent", " - cxl/pci: Fix the incorrect check of pci_read_config_word() return", " - cxl/pci: Convert PCIBIOS errors to errno on DVSEC config accesses", " - netfilter: cttimeout: detach dataplane timeout policy and repurpose", " refcount", " - arm64: dts: imx94: fix DDR PMU interrupt number", " - arm64: dts: freescale: fsl-ls1028a-tqmls1028a-mbls1028a: switch mmc", " aliases", " - selftests/bpf: Fix flaky file_reader test", " - riscv: alternative: Use IS_ENABLED() over ifdeffery for", " apply_vdso_alternatives()", " - riscv: alternative: Pass vDSO start as parameter to", " apply_vdso_alternatives()", " - riscv: alternative: Also patch the CFI vDSO", " - bpf: Verifier support for sleepable tracepoint programs", " - bpf: Reject sleepable BPF_LSM_CGROUP programs at load time", " - netfilter: flowtable: avoid num_encaps underflow on bridge VLAN untag", " - filelock: fix break_lease() stub signature for CONFIG_FILE_LOCKING=n", " - wifi: mac80211: bound S1G TIM PVB walk to the TIM element", " - ACPI: processor: Add cpuidle driver check in", " acpi_processor_register_idle_driver()", " - RDMA/nldev: Fix locking when accessing mr->pd", " - scsi: ufs: core: Handle PM commands timeout before SCSI EH", " - iommufd: Destroy the pages content after detaching from dmabuf", " - lib/test_hmm: fix memory leak in dmirror_migrate_to_system()", " - rust: kbuild: show the right `quiet_cmd_rustc_procmacrolibrary`", " - remoteproc: qcom_q6v5_wcss: drop redundant wcss_q6_bcr_reset", " - wifi: mt76: mt7996: remove redundant pdev->bus check in probe", " - wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bits", " - memory: tegra186-emc: stop borrowing MC aggregate hook for EMC", " - PM: QoS: Fix misc device registration unwind", " - btrfs: lzo: reject compressed segment that overflows the compressed", " input", " - ixgbe: do not configure xps for XDP queues", " - bpf: Cancel special fields on map value recycle", " - clocksource: move NXP timer selection to drivers/clocksource", " - [Config] Allow certain NXP timer selections for arm64", " - vduse: fix compat handling for VDUSE_IOTLB_GET_FD/VDUSE_VQ_GET_INFO", " - iomap: pass the correct len to fserror_report_io in __iomap_write_begin", " - ASoC: cs35l56: Prevent double-free of debugfs", " - ASoC: cs35l56: Cleanup if component_probe fails", " - hwmon: (gpd-fan): drop global driver data and use per-device allocation", " - hwmon: (gpd-fan): Initialize EC before registering hwmon device", " - hwmon: (gpd-fan): fix race condition between device removal and sysfs", " access", " - ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT", " - cxl/test: Verify cmd->size_in before accessing payload", " - m68k: mcf5441x: fix clocks numbering", " - pinctrl: airoha: an7583: add missed gpio32 pin group", " - pinctrl: airoha: an7583: fix misprint in gpio19 pinconf", " - pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin", " function", " - pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin", " function", " - pinctrl: airoha: fix pwm pin function for an7581 and an7583", " - pinctrl: airoha: an7583: fix gpio21 pin group", " - pinctrl: airoha: an7583: add missed gpio22 pin group", " - pinctrl: airoha: an7583: fix phy1_led1 pin function", " - pinctrl: airoha: an7583: remove undefined groups from pcm_spi pin", " function", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_setup() for non-", " serdev device", " - Bluetooth: btintel: Replace CNVi id with hardware variant", " - Bluetooth: btintel: Add DSBR support for ScP2 onwards", " - Bluetooth: btintel_pcie: Load IOSF debug regs by controller variant", " - ASoC: cs35l56: Fix wrong error test on simple_write_to_buffer()", " - ASoC: SOF: Intel: select SND_SOC_SDW_UTILS=y from", " SND_SOC_SOF_HDA_GENERIC=y", " - ASoC: meson: aiu: Validate written enum values", " - ASoC: topology: Check PCM and DAI name strings before use", " - ipv4: fib: Don't dump dying fib_info in fib_leaf_notify().", " - iommu/dma-iommu: Fix wrong scatterlist length assignment in P2PDMA path", " - iommufd: Clarify IOAS_MAP_FILE dma-buf support", " - cxl/region: Fill first free targets[] slot during auto-discovery", " - vfio: selftests: Ensure libvfio output dirs are always created", " - cxl/region: Block region delete during region creation", " - cxl/region: Resolve region deletion races", " - cxl/memdev: Pin parents for entire memdev lifetime", " - net: airoha: Fix error handling in airoha_ppe_flush_sram_entries()", " - netfilter: nft_fwd_netdev: use recursion counter in neigh egress path", " - netfilter: nf_dup_netdev: add nf_dev_xmit_recursion*() helpers and use", " them", " - geneve: Fix off-by-one comparing with GRO_LEGACY_MAX_SIZE", " - smb: client: fix conflicting option validation for new mount API", " - btrfs: Drop WQ_PERCPU from ordered_flags in btrfs_init_workqueues()", " - bpf: Guard __get_user acesss with access_ok for uprobe_multi data", " - net: ti: icssg-prueth: Fix AF_XDP fill ring alloc and wakeup condition", " - net: ti: icssg: Use undirected TX tag for native XDP in HSR offload mode", " - net: ti: icssg: Use undirected TX tag for XDP zero copy in HSR offload", " mode", " - RDMA/bnxt_re: Free CQ toggle page after firmware teardown", " - RDMA/bnxt_re: Reject GET_TOGGLE_MEM when toggle page was not allocated", " - RDMA/hns: Fix memory leak of bonding resources", " - mfd: bd72720: Drop BUCK11 ID", " - 9p: Add missing read barrier in virtio zero-copy path", " - perf dwarf-aux: Fix libdw segmentation fault in cu_walk_functions_at", " - perf dwarf-aux: Fix libdw API contract violations", " - perf srcline: Introduce inline_node__clear_frames()", " - perf libdw: Fix libdw API contract violations and memory leaks", " - perf probe-finder: Fix libdw API contract violations", " - perf annotate-data: Fix libdw API contract violations", " - coresight: tmc: Fix overflow when calculating is bigger than 2GiB", " - perf tool: Fix missing schedstat delegates and dont_split_sample_group", " in delegate_tool", " - PCI: intel-gw: Move interrupt enable to own function", " - PCI: intel-gw: Enable clock before PHY init", " - PCI: intel-gw: Add .start_link() callback", " - bus: mhi: ep: Add missing state_lock protection for mhi_state access", " - PCI: dwc: Apply ECRC workaround for DesignWare cores prior to 5.10a", " - PCI: qcom: Set max OPP before DBI access during resume", " - perf pmu-events AMD: Switch l2_itlb_misses to", " bp_l1_tlb_miss_l2_tlb_miss.all", " - perf unwind: Refactor get_entries to allow dynamic libdw/libunwind", " selection", " - coresight: Handle helper enable failure properly", " - mailbox: don't free the channel if the startup callback failed", " - PCI/pwrctrl: Lock device when calling device_is_bound()", " - coresight: platform: defer connection counter increment until alloc", " succeeds", " - platform/x86: classmate-laptop: Address memory leaks on driver removal", " - clk: microchip: mpfs-ccc: fix peripheral driver registration failures", " after oob fix", " - perf sample: Add evsel to struct perf_sample", " - perf event: Fix size of synthesized sample with branch stacks", " - perf inject: Fix itrace branch stack synthesis", " - gpib: cb7210: Fix region leak when request_irq fails", " - timers/migration: Update stale @online doc to @available", " - clk: spacemit: k3: Switch to pll2_d6 as parent for PCIe clock", " - clk: spacemit: k3: Fix PCIe clock register offset", " - fs/ntfs3: fix wrong LCN in run_remove_range() when splitting a run", " - ntfs3: Allocate iomap inline_data using alloc_page", " - perf sample: Add file_offset field to struct perf_sample", " - perf sched: Replace BUG_ON on invalid CPU with graceful skip", " - perf sched: Fix NULL dereference in latency_runtime_event", " - perf sched: Fix comp_cpus heap overflow with cross-machine recordings", " - perf tools: Guard remaining test_bit calls from OOB sample CPU", " - perf sched: Fix thread reference leaks in timehist_get_thread()", " - perf sched: Use is_idle_sample() for idle thread runtime cast guard", " - perf sched: Fix thread reference leak in idle hist processing", " - perf sched: Free callchain nodes in idle thread cleanup", " - docs: memfd_preservation: fix rendering of ABI documentation", " - virtio: add missing kernel-doc for map and vmap members", " - fs/ntfs3: prevent potential lcn remains uninitialized", " - perf tools: NULL bitmap pointers after bitmap_free()", " - perf tools: Use scnprintf() in build_id__snprintf() and hwmon", " read_events()", " - perf data convert json: Fix addr_location leak on time-filtered samples", " - perf tools: Use mkostemp() for O_CLOEXEC on temporary files", " - phy: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put", " in reset", " - sparc: Avoid -Wunused-but-set-parameter in clear_user_page()", " - apparmor: release exe file resources on path failure", " - apparmor: remove unnecessary goto and associated label", " - apparmor: Fix inverted comparison in cache_hold_inc()", " - i3c: mipi-i3c-hci: Fix suspend behavior when bus disable falls back to", " software reset", " - i3c: master: Serialize i3c_set_hotjoin() with the maintenance lock", " - i3c: mipi-i3c-hci: Fix race in i3c_hci_addr_to_dev()", " - perf maps: Add maps__mutate_mapping", " - perf c2c: Free format list entries when releasing c2c hist entries", " - regcache: Do not overwrite error code when finalizing cache after error", " - erofs: call erofs_exit_ishare() before rcu_barrier()", " - perf c2c: Free format list entries when c2c_hists__init() fails", " - perf c2c: Fix hist entry and format list leaks in c2c_he_free()", " - drm/amd/display: Skip PHY SSC reduction on some 8K panels", " - net: ethernet: mtk_eth_soc: fix supported_interface set after", " phylink_create", " - selftests/ftrace: Fix trace_marker_raw test on 64K page kernels", " - octeontx2-af: npc: Log successful MCAM drop-on-non-hit install at debug", " level", " - netconsole: don't drop the last byte of a full-sized message", " - eth: fbnic: take netif_addr_lock_bh() around rx mode address programming", " - arm64: static_call: include asm/insns.h", " - md/raid1: fix writes_pending and barrier reference leaks on write", " failures", " - md/raid10: fix writes_pending leak on write request failures", " - md/raid10: fix writes_pending and barrier reference leaks on discard", " failures", " - netfilter: ipset: Don't use test_bit() in lockless RCU readers in bitmap", " types", " - selftests/mm: fix hugetlb pathname construction in", " charge_reserved_hugetlb.sh", " - selftests/mm: run_vmtests.sh: free memory if available memory is low", " - selftests/mm: move hwpoison setup into run_test() and silence modprobe", " output for memory-failure category", " - selftests/mm: remove hardcoded THP sizing assumptions in hmm tests", " - net: dst_metadata: fix false-positive memcpy overflow in tun_dst_unclone", " - bpf: Fix partial copy of non-linear test_run output", " - bpf: Fix BPF_PROG_ASSOC_STRUCT_OPS last field check", " - erofs: handle 48-bit blocks_hi for compressed inodes", " - ASoC: cs530x: Fix expected MCLK rates for CS5302/4/8", " - PCI: endpoint: pci-epf-vntb: Document legacy MSI doorbell offset", " - PCI: endpoint: pci-epf-vntb: Defer pci_epc_raise_irq() out of atomic", " context", " - PCI: endpoint: pci-epf-vntb: Report 0-based doorbell vector via", " ntb_db_event()", " - e1000e: Reconfigure PLL clock gate timeout and re-enable K1 on Meteor", " Lake", " - bpf: Guard conntrack opts error writes", " - selftests/bpf: Cover small conntrack opts error writes", " - netfilter: nf_conntrack_helper: dynamically allocate struct", " nf_conntrack_helper", " - netfilter: nf_conntrack_pptp: move GRE specific cleanup to GRE tracker", " - netfilter: nf_conntrack_gre: fix gre keymap list corruption", " - netfilter: conntrack: check NULL when retrieving ct extension", " - netfilter: nf_conntrack_expect: use conntrack GC to reap expectations", " - netfilter: nf_conntrack_expect: store master_tuple in expectation", " - netfilter: nf_conntrack_expect: run expectation eviction with no helper", " - netfilter: nft_ct: expectation timeouts are passed in milliseconds", " - netfilter: nf_conntrack_helper: cap maximum number of expectation at", " helper registration", " - cpuidle: Allow exit latency to exceed target residency", " - ASoC: SDCA: Validate written enum value in ge_put_enum_double()", " - ASoC: rt5575: Use __le32 for SPI burst write address", " - PCI: endpoint: pci-epf-vntb: Exclude reserved slots from db_valid_mask", " - net: ti: icssg: Fix XSK zero copy TX during application wakeup", " - net: lwtunnel: Drop skb metadata before LWT encapsulation", " - sctp: fix err_chunk memory leaks in INIT handling", " - net: dsa: mxl862xx: avoid unaligned 16-bit access in api_wrap", " - octeontx2-af: fix CGX debugfs RVU AF PCI reference leaks", " - geneve: gate GRO hint in geneve_gro_complete() on gs->gro_hint", " - geneve: validate inner network offset in geneve_gro_complete()", " - tools: ynl: build archives with $(AR)", " - net: enetc: fix potential divide-by-zero when num_vsi is zero", " - udp_tunnel: Pass struct sock to setup_udp_tunnel_sock().", " - tipc: avoid busy looping in tipc_exit_net()", " - bpf: Mask pseudo pointer values in verifier logs", " - bpf: Fix insn_aux_data leak on verifier err_free_env path", " - hwmon: (pmbus/core) Add support for NVIDIA nvidia195mv mode", " - hwmon: (pmbus/core) honor vrm_version in pmbus_data2reg_vid()", " - gpio: shared-proxy: always serialize with a sleeping mutex", " - drm/panthor: Always use the IRQ-safe variant when acquiring the fence", " lock", " - drm/panthor: Keep the reset work disabled until everything is", " initialized", " - drm/panthor: Fix panthor_pwr_unplug()", " - spi: rzv2h-rspi: Fix DMA transfer error handling for signal interruption", " - xen/pvcalls: bound backend response req_id before indexing rsp[]", " - afs: Remove setting of AS_RELEASE_ALWAYS for symlinks and mountpoints", " - afs: Fix directory inode initialisation order", " - afs: Use scoped_seqlock_read() rather than manually doing seqlock stuff", " - afs: Fix leak of ungot volume", " - iomap: release pages on atomic dio size mismatch", " - cachefiles: Fix double unlock in nomem_d_alloc error path", " - cachefiles: Fix file burial to take lock when unsetting S_KERNEL_FILE", " - drm/imagination: Fix returned size for DRM_IOCTL_PVR_DEV_QUERY", " - iio: dac: mcp47feb02: Fix passing uninitialized vref1_uV for no Vref1", " case", " - net/mlx5: LAG, replace pf array with xarray", " - net/mlx5: LAG, use xa_alloc to manage LAG device indices", " - net/mlx5: Lag: refactor representor reload handling", " - net/mlx5: E-Switch, add representor lifecycle lock", " - net/mlx5: Lag, avoid LAG and representor lock cycles", " - net/mlx5: LAG, factor out shared FDB code into dedicated file", " - net/mlx5: LAG, replace peer count check with direct peer lookup", " - net/mlx5: LAG, prepare for SD device integration", " - net/mlx5: LAG, replace mlx5_get_dev_index with LAG sequence number", " - net/mlx5: LAG, extend shared FDB API with group_id filter", " - net/mlx5: LAG, Fix off-by-one in single-FDB error rollback", " - ksmbd: fix multichannel binding and enforce channel limit", " - smb: client: preserve leading slash for POSIX absolute symlink targets", " - gpio: shared: make the voting mechanism adaptable", " - drm/i915/ltphy: Fix SSC Enablement bit in PORT_CLOCK_CTL", " - Bluetooth: 6lowpan: avoid untracked enable work", " - Bluetooth: btintel_pcie: Support Product level reset", " - [Config] Make BT_INTEL_PCIE depend on ACPI", " - Bluetooth: btintel_pcie: Add support for smart trigger dump", " - Bluetooth: btintel_pcie: Separate coredump work from RX work", " - Bluetooth: btintel_pcie: Refactor FLR to use device_reprobe()", " - Bluetooth: ISO: fix malformed ISO_END/CONT handling", " - accel/amdxdna: Prevent PM resume deadlock in hwctx_sync_debug_bo()", " - accel/amdxdna: Fix VMA access race", " - net: rnpgbe: fix mailbox endianness and remove pointer casts", " - drm: Guard DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE", " - smb: client: fix busy dentry warning on unmount after DIO", " - drm/fb-helper: Only consider active CRTCs for vblank sync", " - ethtool: rss: Fix hfunc and input_xfrm parsing on big endian", " - drm/imagination: make pvr_fw_trace_init_mask_ops static", " - VDUSE: avoid leaking information to userspace", " - ASoC: SOF: ipc4-control: Validate notification payload size", " - arm64: dts: renesas: ironhide: Describe inline ECC carveouts", " - arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers", " - KVM: s390: vsie: Fix allocation of struct vsie_rmap", " - KVM: s390: vsie: Add missing radix_tree_preload() in", " _gaccess_shadow_fault()", " - KVM: s390: Add some useful mask macros", " - KVM: s390: vsie: Fix rmap handling in _do_shadow_crste()", " - KVM: s390: vsie: Fix redundant rmap entries", " - KVM: s390: vsie: Use mmu cache to allocate rmap", " - KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory", " - KVM: TDX: Reject concurrent change to CPUID entry count", " - ASoC: SOF: topology: fix memory leak in snd_sof_load_topology", " - netfilter: nft_fib: reject fib expression on the netdev egress hook", " - netfilter: nf_conntrack_sip: remove net variable shadowing", " - netfilter: nf_conntrack_sip: validate skb_dst() before accessing it", " - gpu/buddy: bail out of try_harder when alignment cannot be honoured", " - backlight: ktd2801: Enable BL_CORE_SUSPENDRESUME", " - cxl: Fix CXL_HEADERLOG_SIZE to match RAS Capability size", " - pinctrl: renesas: rzg2l: Use -ENOTSUPP instead of -EOPNOTSUPP", " - remoteproc: xlnx: Check remote core state", " - mm/sparse-vmemmap: fix vmemmap accounting underflow", " - mm/huge_memory: preserve pmd_swp_uffd_wp on device-private PMD downgrade", " - fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race", " - fs/proc/task_mmu: do not warn on seeing non-migration pmd entry", " - kho: make sure scratch size is always aligned by CMA_MIN_ALIGNMENT_BYTES", " - mtd: maps: vmu-flash: fix fault in unaligned fixup", " - dmaengine: dw-edma-pcie: Reject devices without driver data", " - dmaengine: sh: rz-dmac: Move interrupt request after everything is set", " up", " - platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8D26)", " - platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8E35)", " - spi: imx: reconfigure for PIO when DMA cannot be started", " - ovl: use linked upper dentry in copy-up tmpfile", " - can: bcm: add locking when updating filter and timer values", " - can: bcm: extend bcm_tx_lock usage for data and timer updates", " - can: bcm: fix CAN frame rx/tx statistics", " - can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()", " - can: bcm: fix stale rx/tx ops after device removal", " - can: bcm: track a single source interface for ANYDEV timeout/throttle", " ops", " - can: bcm: validate frame length in bcm_rx_setup() for RTR replies", " - can: bcm: add missing device refcount for CAN filter removal", " - selftests/bpf: Cover negative buffer pointer offsets", " - dm: avoid leaking the caller's thread keyring via the table device file", " - dma-buf: protected fence ops by RCU v8", " - dma-fence: use correct callback in dma_fence_timeline_name()", " - accel/amdxdna: reject command submission on devices without a submit op", " - accel/amdxdna: reject user command submission without a command BO", " - accel/amdxdna: Use caller client for debug BO sync", " - fs/resctrl: Fix use-after-free during unmount", " - mmc: vub300: fix use-after-free on probe failure", " - octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF", " - ksmbd: fix stack buffer overflow in multichannel session-key copy", " - netfilter: nfnetlink_cthelper: cap to maximum number of expectation per", " master", " - netfilter: nfnetlink_cthelper: cap to maximum number of expectation per", " master on updates", " - riscv: vdso: Always declare vdso_start symbols", " - ata: libata-core: Add NOLPM quirk for PNY CS900 1TB SSD", " - ata: libata-core: Reject an invalid concurrent positioning ranges count", " - net: ipa: fix SMEM state handle leaks in SMP2P init", " - amdkfd: properly free secondary context id", " - pmdomain: imx93-blk-ctrl: Extract PHY as shared domain for DSI/CSI", " - pmdomain: mediatek: Fix possible nullptr KP in HWV cleanup/on-check", " - arch/riscv: vdso: remove CFI landing pad from rt_sigreturn", " - reset: imx7: Correct polarity of MIPI CSI resets on i.MX8MQ", " - powerpc/uaccess: correct check for CONFIG_PPC_E500 in", " mask_user_address()", " - wifi: mac80211: validate extension-frame layout before RX", " - xfs: factor out a xfs_zone_mark_free helper", " - xfs: add newly added RTGs to the free pool in growfs", " - liveupdate: validate session type before performing operation", " - posix-timers: Expand timer_[re]arm() callbacks with a boolean return", " value", " - posix-cpu-timers: Prevent UAF caused by non-leader exec() race", " - Revert \"gpib: cb7210: Fix region leak when request_irq fails\"", " - Upstream stable to v6.18.40, v7.1.5", " * Resolute update: upstream stable patchset 2026-08-20 (LP: #2164666) //", " CVE-2023-20585", " - 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", " * [Regression] Laptop fails to power off completely when HDMI is connected", " in kernel 7.0.0-28 (LP: #2163121) // CVE-2026-68364", " - drm/amd/display: fix NULL ptr deref in ISM delayed work", " - drm/amd/display: Fix ISM teardown crash from NULL dc dereference", " - drm/amd/display: Fix ISM dc_lock deadlock during suspend", " * CVE-2026-72064", " - net: mana: Sync page pool RX frags for CPU", " * CVE-2026-72065", " - net: mana: Validate the packet length reported by the NIC", " * CVE-2026-72098", " - dm-verity-fec: replace {MAX,MIN}_RSN with {MIN,MAX}_ROOTS", " - dm-verity: fix buffer overflow in FEC calculation", " * CVE-2026-72248", " - netfilter: flowtable: support IPIP tunnel with direct xmit", " - netfilter: flowtable: use correct direction to set up tunnel route", " * CVE-2026-72249", " - netfilter: flowtable: use dst in this direction when pushing IPIP header", " * CVE-2026-72287", " - KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\"", " checks", " * CVE-2026-72329", " - net/liquidio: drop cached VF pci_dev LUT", " * CVE-2026-72355", " - netfs: Fix barriering when walking subrequest list", " * CVE-2026-72412", " - s390/mm: Fix handling of _PAGE_UNUSED pte bit", " * CVE-2026-72417", " - netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto()", " * CVE-2026-72442", " - netfilter: flowtable: fix and simplify IP6IP6 tunnel handling", " * CVE-2026-72463", " - xfrm: Fix dev use-after-free in xfrm async resumption", " * CVE-2026-72477", " - fs/ntfs3: call _ntfs_bad_inode() when failing to rename", " * CVE-2026-72493", " - net: serialize netif_running() check in enqueue_to_backlog()", " * CVE-2026-72494", " - RDMA/irdma: Replace waitqueue and flag with completion", " * CVE-2026-72496", " - RDMA/bnxt_re: Proper rollback if the ioremap fails", " * CVE-2026-74269", " - bnxt: fix head underflow on XDP head-grow", " * CVE-2026-74350", " - ocfs2: validate fast symlink target during inode read", " * CVE-2026-72495", " - RDMA/bnxt_re: Avoid repeated requests to allocate WC pages", " * CVE-2026-72501", " - RDMA/bnxt_re: Initialize dpi variable to zero", " * CVE-2026-72278", " - KVM: arm64: nv: Re-translate VNCR before injecting abort", " * CVE-2026-68083", " - ksmbd: fix path resolution in ksmbd_vfs_kern_path_create", " * CVE-2026-68457", " - ksmbd: use opener credentials for FSCTL mutations", " * CVE-2026-68476", " - ipvs: reload ip header after head reallocation", " * CVE-2026-68477", " - ipvs: fix more places with wrong ipv6 transport offsets", " * CVE-2026-72014", " - drbd: reject data replies with an out-of-range payload size", " * CVE-2026-72020", " - ipvs: reset full ip_vs_seq structs in ip_vs_conn_new", " * CVE-2026-72033", " - orangefs: keep the readdir entry size 64-bit in fill_from_part()", " * CVE-2026-72041", " - espintcp: use sk_msg_free_partial to fix partial send", " * CVE-2026-72046", " - gve: fix header buffer corruption with header-split and HW-GRO", " * CVE-2026-72069", " - locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()", " * CVE-2026-72083", " - scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE", " * CVE-2026-72084", " - scsi: target: Bound PR-OUT TransportID parsing to the received buffer", " * CVE-2026-72085", " - scsi: xen: scsiback: Free unsubmitted command instead of double-putting", " it", " * CVE-2026-72129", " - nvmet-rdma: handle inline data with a nonzero offset", " * CVE-2026-72130", " - nvmet-auth: reject short AUTH_RECEIVE buffers", " * CVE-2026-64551", " - sctp: validate STALE_COOKIE cause length before reading staleness", " * CVE-2026-72137", " - xfrm: nat_keepalive: avoid double free on send error", " * CVE-2026-72139", " - tcp: defer md5sig_info kfree past RCU grace period in tcp_connect", " * CVE-2026-72191", " - ntfs3: validate split-point offset in indx_insert_into_buffer", " * CVE-2026-72192", " - ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head", " * CVE-2026-72194", " - fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow", " * CVE-2026-72217", " - SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing", " * CVE-2026-72220", " - sunrpc: harden rq_procinfo lifecycle to prevent double-free", " * CVE-2026-72221", " - sunrpc: wait for in-flight TLS handshake callback when cancel loses race", " * CVE-2026-72222", " - sunrpc: pin svc_xprt across the asynchronous TLS handshake callback", " * CVE-2026-72226", " - batman-adv: tt: prevent TVLV OOB check overflow", " * CVE-2026-72234", " - batman-adv: access unicast_ttvn skb->data only after skb realloc", " * CVE-2026-72251", " - netfilter: nf_nat_sip: reload possible stale data pointer", " * CVE-2026-72277", " - KVM: arm64: nv: Inject SEA if kvm_translate_vncr() can't resolve PFN", " - KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory", " * CVE-2026-72279", " - KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR", " * CVE-2026-72288", " - KVM: arm64: vgic: Handle race between interrupt affinity change and LPI", " disabling", " * CVE-2026-72289", " - KVM: arm64: vgic: Check the interrupt is still ours before migrating it", " * CVE-2026-72296", " - net: ife: require ETH_HLEN to be pullable in ife_decode()", " * CVE-2026-72299", " - tipc: restrict socket queue dumps in enqueue tracepoints", " * CVE-2026-72317", " - SUNRPC: pin upper rpc_clnt across the TLS connect_worker", " * CVE-2026-72318", " - cifs: validate DFS referral string offsets", " * CVE-2026-72319", " - ipvs: fix PMTU for GUE/GRE tunnel ICMP errors", " - ipvs: ensure inner headers in ICMP errors are in headroom", " * CVE-2026-72320", " - netfilter: nft_lookup: fix catchall element handling with inverted", " lookups", " * CVE-2026-72322", " - ipv6: mcast: Fix potential UAF in MLD delayed work", " * CVE-2026-72323", " - ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()", " * CVE-2026-64541", " - net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket", " * CVE-2026-72339", " - qede: fix off-by-one in BD ring consumption on build_skb failure", " * CVE-2026-72348", " - netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop", " * CVE-2026-72351", " - gue: validate REMCSUM private option length", " * CVE-2026-72366", " - netfs: Fix netfs_create_write_req() to handle async cache object", " creation", " * CVE-2026-72381", " - ksmbd: fix use-after-free of fp->owner.name in durable handle owner", " check", " * CVE-2026-72393", " - eth: fbnic: don't cache shinfo across skb realloc", " * CVE-2026-72398", " - sctp: add INIT verification after cookie unpacking", " * CVE-2026-72399", " - net: enetc: check the number of BDs needed for xdp_frame", " * CVE-2026-64530", " - net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle", " * CVE-2026-72422", " - ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2", " NEGOTIATE", " * CVE-2026-72429", " - ipv6: ioam: fix type confusion of dst_entry", " * CVE-2026-72436", " - 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", " * CVE-2026-72451", " - xfrm: Fix xfrm state cache insertion race", " * CVE-2026-72466", " - xprtrdma: Fix bcall rep leak and unbounded peek", " * CVE-2026-72472", " - nfs: use nfsi->rwsem to protect traversal of the file lock list", " * CVE-2026-72473", " - 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", " * CVE-2026-72491", " - net/9p: fix race condition on rdma->state in trans_rdma.c", " * CVE-2026-72495 // CVE-2026-72501", " - RDMA/bnxt_re: Move the UAPI methods to a dedicated file", " * CVE-2026-74255", " - tipc: fix UAF in tipc_l2_send_msg()", " * CVE-2026-74267", " - net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek", " before restoring qlen", " * CVE-2026-74268", " - tcp: clear sock_ops cb flags before force-closing a child socket", " * CVE-2026-74287", " - sctp: validate embedded address parameter length", " * CVE-2026-74310", " - vhost/net: complete zerocopy ubufs only once", " * CVE-2026-74345", " - RDMA/siw: Fix endpoint/socket association handling", " * CVE-2026-74361", " - nvme: fix FDP fdpcidx bounds check", " * CVE-2026-74376", " - md/raid10: reset read_slot when reusing r10bio for discard", " * CVE-2026-74384", " - nvme-multipath: fix flex array size in struct nvme_ns_head", " * CVE-2026-74394", " - RDMA/srpt: fix integer overflow in immediate data length check", " * CVE-2026-74398", " - ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD", " * CVE-2026-74401", " - dlm: fix add msg handle in send_queue ordered", " * CVE-2026-74406", " - vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().", " * CVE-2026-74427", " - afs: Fix netns teardown to cancel the preallocation charger", " - afs: Fix further netns teardown to cancel the preallocation charger", " * CVE-2026-74428", " - rxrpc: Fix double unlock in rxrpc_recvmsg()", " * CVE-2026-74433", " - rxrpc: Fix UAF in rxgk_issue_challenge()", " * CVE-2026-74434", " - rxrpc: Don't move a peeked OOB message onto the pending queue", " * CVE-2026-74436", " - rxrpc: serialize kernel accept preallocation with socket teardown", " * CVE-2026-64535", " - nvmet-tcp: Fix potential UAF when ddgst mismatch", " * CVE-2026-74439", " - iommu/vt-d: Clear Present bit before tearing down scalable-mode context", " entry", " * CVE-2026-64534", " - nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error", " path", "" ], "package": "linux-riscv-7.0", "version": "7.0.0-38.38.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2165483, 2165484, 2165407, 2166547, 2166443, 2166356, 2165872, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165189, 2165407, 2165040, 2161748, 2163508, 2163214, 2162904, 2162045, 2164967, 2160082, 2164504, 2156316, 2164716, 2164516, 2163375, 2162803, 2163062, 2132119, 2163293, 2160200, 2158858, 2162704, 2162695, 2164666, 2164666, 2163121 ], "author": "Sarah Emery ", "date": "Sun, 27 Sep 2026 00:11:21 +0200" } ], "notes": "linux-tools-7.0.0-38-generic version '7.0.0-38.38.1~24.04.1' (source package linux-riscv-7.0 version '7.0.0-38.38.1~24.04.1') was added. linux-tools-7.0.0-38-generic version '7.0.0-38.38.1~24.04.1' has the same source package name, linux-riscv-7.0, as removed package linux-headers-7.0.0-34-generic. As such we can use the source package version of the removed package, '7.0.0-34.34.1~24.04.1', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-headers-7.0.0-34-generic", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-7.0.0-34-generic", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-modules-7.0.0-34-generic", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-riscv-7.0-headers-7.0.0-34", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-riscv-7.0-tools-7.0.0-34", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-tools-7.0.0-34-generic", "from_version": { "source_package_name": "linux-riscv-7.0", "source_package_version": "7.0.0-34.34.1~24.04.1", "version": "7.0.0-34.34.1~24.04.1" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "notes": "Changelog diff for Ubuntu 24.04 noble image from release image serial 20260926 to 20261017", "from_series": "noble", "to_series": "noble", "from_serial": "20260926", "to_serial": "20261017", "from_manifest_filename": "release_manifest.previous", "to_manifest_filename": "manifest.current" }